EmailDNSDeliverability

Email DNS: MX, SPF, DKIM, DMARC

By Harry Osmar Sitohang·Jun 2026·8 min

We want two things from [email protected]: mail that keeps flowing after the DNS move, and the ability to read and send it from a normal Gmail. The mailbox itself is Hostinger Email; the DNS records that make email work now live on Cloudflare (grey-cloud, carried over when we moved the domain). Here's how those records actually work — in plain English.

Two directions: ingress vs egress

The cleanest way to understand email's DNS records is to split them by direction of travel — mail coming in to you (ingress) versus mail going out from you (egress). Different records govern each, and — this is the part that surprises people — some are checked on someone else's server, not yours.

Four actors, two directions. INGRESS: [email protected] → Cloudflare (MX) → mail.hostinger.com. EGRESS: sales@ signs with its private key; [email protected] runs SPF (allowed sending server?) AND DKIM (public-key signature check?) against Cloudflare DNS — both feed DMARC, which delivers on an aligned pass or applies the policy (p=none monitors) when both fail.

Ingress — mail coming in (→ `sales@`), governed by MX

MX stands for Mail eXchange, and it answers one question: "where should mail addressed to @pangaea.id be delivered?"

Follow it from the sender's point of view: someone emails [email protected] → their mail server does an MX lookup in DNS → DNS replies mx1.hostinger.com (priority 5) and mx2.hostinger.com (priority 10) → the sender connects over SMTP and delivers the message to Hostinger, where the mailbox lives. (Lower priority number = tried first; mx2 is the backup.)

Egress — mail going out (from `@pangaea.id` →), governed by SPF + DKIM + DMARC

Here's the key idea: you publish these three records, but they're checked by the recipient's mail server (Gmail, Outlook…) the moment your message lands on their side. So they're your outbound identity, verified at the receiver's end.

SPF — Sender Policy Framework. A published allow-list of the servers permitted to send mail "as" your domain. The receiver asks: did this come from a server pangaea.id authorised?
```
v=spf1 include:_spf.mail.hostinger.com ~all
```
(~all is a softfail: anything not from Hostinger is treated as suspicious, not hard-rejected.)
DKIM — DomainKeys Identified Mail. Hostinger cryptographically signs each outgoing message with a secret private key; you publish the matching public key in DNS so the receiver can verify the signature. That proves the mail (a) genuinely came from your domain and (b) wasn't altered in transit. It's published as CNAME "selectors" — e.g. hostingermail-a._domainkey → hostingermail-a.dkim.mail.hostinger.com (selector -a carries the live key; -b, -c are spares).
DMARC — Domain-based Message Authentication, Reporting & Conformance. It ties SPF + DKIM together, tells the receiver what to do when a message fails (p=none = monitor, p=quarantine = spam, p=reject = refuse), and emails you reports (rua=). It also enforces alignment: the visible From: domain must match what SPF/DKIM verified.
```
v=DMARC1; p=none; rua=mailto:[email protected]
```
(Currently monitor-only — start gentle, watch the reports, tighten to quarantine/reject later.)

MX is the loading-dock address; SPF, DKIM and DMARC are the wax seal, letterhead and return-policy that prove your outbound mail is genuinely from you — and they're all checked at the recipient's end.

— the one-line mental model

The records at a glance — and who checks each

The column people miss is the last one:

MX — Mail eXchange · ingress · where to deliver mail to you · read by the sender's server
SPF — Sender Policy Framework · egress · which servers may send as you · the recipient's
DKIM — DomainKeys Identified Mail · egress · a tamper-proof signature on each mail · the recipient's
DMARC — …Authentication, Reporting & Conformance · egress · what to do if SPF/DKIM fail (+ reports) · the recipient's

Read & send `sales@` from your normal Gmail

Receive — either set forwarding (Hostinger → your Gmail), or pull it in: Gmail → Settings → Accounts and Import → Check mail from other accounts → POP pop.hostinger.com, port 995, SSL.

Send as — Gmail → Accounts and Import → Send mail as → SMTP smtp.hostinger.com, port 465 (SSL), username [email protected], the mailbox password. Confirm via the code Google emails you. Now you can send as [email protected] from the same inbox you already use.

Carrying the records when DNS moves to Cloudflare

The #1 migration mistake

Adding DKIM as a TXT record. Hostinger Email's DKIM is a CNAME — the wrong type and your mail starts getting flagged. Copy the exact selector and target from Hostinger's panel.

We did exactly this when the domain moved to Cloudflare — the migration-day story (and the CAA record that nearly broke the padlock weeks later) is in Moving DNS without dropping the mail →.

Common questions

When someone emails [email protected], how does it reach our mailbox?

That's ingress — incoming mail — governed by the MX record. MX stands for Mail eXchange, and it answers exactly one question: "where should mail for @pangaea.id be delivered?" The sender's mail server looks up our MX in DNS, gets back mx1.hostinger.com (priority 5) and mx2.hostinger.com (priority 10), and delivers the message to Hostinger, where the mailbox actually lives. A lower priority number is tried first, so mx2 is just the backup.

Who reads the MX record — us or the sender?

The sender's server. That surprises people: MX is a public note you publish, but it's other people's mail servers that read it to figure out where to ship mail addressed to you.

What are SPF, DKIM and DMARC, and why do we need three of them?

They're the egress (outgoing) records — together they prove that mail claiming to be from @pangaea.id really is from you. Plain SMTP (the mail protocol) has no built-in way to prove a sender, so these bolt that on:

SPF (Sender Policy Framework) is a published allow-list of servers permitted to send "as" your domain. Ours is v=spf1 include:_spf.mail.hostinger.com ~all — the ~all means "treat anything not from Hostinger as suspicious."
DKIM (DomainKeys Identified Mail) is a cryptographic signature on each message: Hostinger signs with a private key, and a matching public key in DNS lets the receiver verify the mail is genuinely yours and wasn't altered.
DMARC (Domain-based Message Authentication, Reporting & Conformance) ties SPF and DKIM together, tells the receiver what to do on failure, and emails you reports. Ours is v=DMARC1; p=none; rua=mailto:[email protected] — p=none is monitor-only for now, and rua= is where the reports go.

Who checks SPF, DKIM and DMARC?

The recipient's server — Gmail, Outlook, and so on — at the moment your message lands on their side. So these three are your outbound identity, but they're verified at the other end. That's the mirror image of MX (read by the sender): ingress is checked by the sender, egress is checked by the recipient.

Why is DMARC set to p=none instead of rejecting bad mail?

p=none is "monitor only" — it asks receivers to report failures but not to block anything yet. It's the safe starting posture: you watch the rua= reports to make sure all your legitimate mail passes SPF/DKIM first, then later you can tighten to p=quarantine (send failures to spam) or p=reject (refuse them). Tightening too early risks bouncing your own real email.

Where this fits

The plain-English diary note is Email that proves itself →. For the rest of the go-live path, start at Point the domain at Cloudflare.

Sources