Mail records: MX, SPF, DKIM and DMARC

To send and receive business email on your own domain through Skyline Cloud, your domain's DNS must carry four records: MX, SPF, DKIM and DMARC. MX tells the world where to deliver your mail; the other three prove that mail claiming to be from your domain is genuine. Getting all four right is what keeps your messages out of recipients' spam folders.

This guide gives you the exact values to publish, explains what each record does in plain language, and shows the difference between Skyline's one-click auto-publish and adding records by hand.

The values to publish

Replace <yourdomain> with your real domain (for example, example.com). For DKIM, the public key is generated for your specific domain inside the portal at Domains -> Email authentication — copy the exact value shown there.

A few notes on the table:

• The DKIM selector is skyline, so the full record name is skyline._domainkey.<yourdomain>.
• Some DNS providers want the bare host (@, skyline._domainkey, _dmarc); others want the fully-qualified name with your domain appended. Use whichever your provider expects — the value stays the same.
• TTL is not critical. Any reasonable default (1 hour / 3600 seconds) is fine.

What each record does

MX — where mail is delivered

The MX (Mail Exchanger) record is the address book entry for your email. When someone sends a message to you@yourdomain, their mail server looks up your domain's MX record to find out which server should receive it. Pointing MX to mail.alskyline.com with priority 10 routes all inbound mail to Skyline Mail, where your mailboxes live. Without a correct MX record, incoming mail simply has nowhere to go.

SPF — who is allowed to send

SPF (Sender Policy Framework) is a TXT record that lists which mail servers are authorized to send email on behalf of your domain. The value v=spf1 include:_spf.alskyline.com -all says "Skyline's sending servers are allowed, and everyone else is not" (-all is a hard fail). Receiving servers check SPF to confirm a message came from a server you approve. This blocks spammers from forging your domain as the sender and is a major signal for deliverability.

DKIM — proof the message wasn't tampered with

DKIM (DomainKeys Identified Mail) adds a cryptographic signature to every message you send. Skyline holds the private signing key; the matching public key is published in DNS at skyline._domainkey.<yourdomain>. The receiving server uses that public key to verify the signature, which proves two things: the message genuinely came from your domain, and it wasn't altered in transit. Because the key is unique to each domain, you must copy the exact value generated for you in the portal under Domains -> Email authentication.

DMARC — the policy that ties it together

DMARC (Domain-based Message Authentication, Reporting and Conformance) tells receiving servers what to do when a message fails SPF or DKIM, and where to send reports. The recommended starting value is:

v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@alskyline.com

• p=quarantine asks receivers to treat failing mail as suspicious (typically routed to spam) rather than rejecting it outright.
• rua=mailto:dmarc-reports@alskyline.com is where aggregate reports are sent, so issues can be spotted.

DMARC is what turns SPF and DKIM into an enforced policy instead of just advisory checks. It's the strongest protection against someone impersonating your domain.

Auto-publish vs. adding records by hand

There are two ways to get these records in place, depending on how your DNS is set up:

• Path A — domain delegated to Skyline. If you've pointed your domain's name servers to ns1.alskyline.com and ns2.alskyline.com, Skyline hosts all of your DNS. In that case the portal's one-click email setup publishes MX, SPF, DKIM and DMARC for you automatically — no manual editing required.
• Path B — DNS stays at your current provider. If you keep DNS where it is, add the four records by hand at that provider, using the exact values the portal shows you (including the per-domain DKIM key from Domains -> Email authentication).

After the records are live, the portal verifies them for you. DNS changes can take up to 24-48 hours to propagate worldwide, so allow time before assuming something is wrong.

Start at quarantine, then move to reject

Begin with p=quarantine. Once you've confirmed over a few days that your legitimate mail is authenticating cleanly (SPF aligned and DKIM signing correctly), tighten the policy to p=reject so that forged mail is refused entirely. The p value is configurable in the portal — change it there once you're confident your mail flow is clean.

v=DMARC1; p=reject; rua=mailto:dmarc-reports@alskyline.com

Need help?

If a record won't verify or your mail isn't flowing as expected, open a support ticket from your portal at cloud.alskyline.com -> Support, and the Skyline team will help you sort it out.