Mail Ward

📮 How an email actually travels

You cannot reason about spoofing until you have seen that an email is really two things at once: an envelope handled by servers, and a letter read by humans. They contain different addresses, and nothing forces them to match.

The two “From” addresses

This gap is the entire attack. A criminal sets the envelope to a domain they legitimately control (so SPF passes for their domain) and writes your address in the From: header. Without DMARC, no one ever compares the two.

Headers worth knowing by name

• Authentication-Results: — the receiving server's verdict. Read this first, always. It is written by the last trusted server, so only trust the copy added by your own provider.
• Received: — one per hop, newest at the top. The bottom-most is where the message was born (and is trivially forgeable; the top ones are not).
• Return-Path: — the envelope sender as recorded on delivery. Compare it with From:.
• DKIM-Signature: — contains d= (the signing domain — the important part), s= (selector), bh= (body hash) and h= (which headers were signed).
• Reply-To: — where your answer really goes. A classic trick: a perfect From: and a hostile Reply-To:.
• Message-ID: — unique id; its domain part often betrays the real sending platform.
• ARC-Seal: / ARC-Authentication-Results: — a forwarder vouching that authentication passed before it touched the message.
• List-Unsubscribe: / List-Unsubscribe-Post: — required by Gmail and Yahoo for bulk senders since 2024; one-click unsubscribe.

Want to read a real message? Paste it into the Email Header Analyzer next door — it decodes all of this for you.

📋 SPF — Sender Policy Framework

A single DNS TXT record on your domain that lists which servers are allowed to send mail using your domain in the envelope. Defined in RFC 7208.

What a record looks like, piece by piece

example.com.  IN  TXT  "v=spf1 ip4:203.0.113.7 include:_spf.google.com include:sendgrid.net -all"

The five rules people break

1. Exactly one SPF record per name. Two v=spf1 TXT records on the same domain is a permanent error and SPF stops working entirely. Merge them into one.
2. Ten DNS lookups, maximum. Counted recursively across every include, a, mx, ptr, exists and redirect. Exceed it and the result is permerror — which most receivers treat as “no SPF”. Flattening tools help but freeze provider IPs; prefer removing unused providers.
3. Do not put SPF in a SPF-type record. DNS record type 99 was retired in 2014. It is a TXT record.
4. SPF does not survive forwarding. When someone auto-forwards your mail, the forwarder becomes the sender and SPF fails. DKIM survives; this is precisely why you need both.
5. SPF alone is invisible to users. It checks the envelope, which nobody reads. It is a building block for DMARC, not a defence in itself.

Void lookups: there is a second, less-known limit — at most 2 mechanisms may resolve to nothing (NXDOMAIN/empty). Stale include: lines for a provider you left behind are the usual culprit.

🔏 DKIM — DomainKeys Identified Mail

Your outgoing server hashes selected headers plus the body and signs them with a private key. The matching public key lives in DNS, so any receiver can verify it. Defined in RFC 6376.

How it hangs together

1. You (or your provider) generate a key pair. The private key stays on the mail platform; the public key becomes a DNS record.
2. The public key is published at <selector>._domainkey.<your-domain>. The selector is just a label, so you can hold several keys at once — that is how rotation works without downtime.
3. Every outgoing message gets a DKIM-Signature: header naming the domain (d=) and the selector (s=).
4. The receiver fetches the key, recomputes the hash, and either verifies the signature or does not.

selector1._domainkey.example.com.  IN  TXT  "v=DKIM1; k=rsa; t=s; p=MIIBIjANBgkqhki…"

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=example.com; s=selector1;
    h=from:to:subject:date:message-id; bh=Wm9…=; b=Hs4…=

Practical rules

• 2048-bit RSA where the provider allows it; 1024 is the old floor and is increasingly frowned upon. Ed25519 exists but support is still patchy — publish it alongside RSA, never instead of it.
• Publish the DNS record before you enable signing, and wait for propagation. Reversing that order means every message you send fails DKIM until DNS catches up.
• Rotate keys every 6–12 months: publish selector2, switch signing to selector2, wait a few days for in-flight mail, then blank out selector1's p=.
• Long TXT records must be split into quoted chunks of ≤255 characters. Most DNS panels do this for you; some do not, and then the key is silently corrupt.
• A leaked private key is a full spoofing licence. If a mail platform is breached, rotate immediately and revoke the old selector with an empty p=.
• DKIM survives forwarding — as long as nothing rewrites the body. Mailing lists that append a footer or edit the subject will break it; that is what ARC was invented for.

🛡️ DMARC — the part that actually protects people

DMARC (RFC 7489) adds the missing question: does the domain that passed SPF or DKIM match the domain your reader sees in the From line? Then it publishes what to do when the answer is no, and asks receivers to report back.

Alignment — read this twice

A message passes DMARC if at least one of these is true:

Relaxed vs strict: by default (adkim=r, aspf=r) a subdomain counts as a match — mail.example.com aligns with example.com. With adkim=s / aspf=s the domains must be identical. Start relaxed; strict is for organisations that have finished the job.

Every DMARC tag

Reading an aggregate report without crying

Reports arrive as gzipped XML, once a day, from every large receiver. Each <record> is one sending IP over one day, and tells you: how many messages, whether SPF and DKIM passed, whether they aligned, and what the receiver did about it. Your job is to put every source into one of four buckets:

Free and paid analysers turn that XML into a dashboard. If you prefer to keep it in-house, a shared mailbox plus a parser is enough — but do not point rua at a personal inbox and then never look at it. An unread report is the same as no report.

External reporting addresses need permission. If rua points at a different domain than the one being reported on, that domain must publish an authorisation record such as example.com._report._dmarc.reporter.net TXT "v=DMARC1", or the reports are silently never sent. This trips up almost everyone using a third-party analyser.

🧩 The rest of the family

SPF, DKIM and DMARC are the core. These are the records that surround them — worth knowing, mostly worth doing, none of them a substitute for the big three.

🪜 The step-by-step plan

Ten steps, in this order. The order matters more than the speed: every step exists to make the next one safe. A small organisation can do this in a month; a large one should budget a quarter. Nobody should do it in an afternoon.

1. 0 Take stock before you touch anything

   Goal — know every system on earth that sends mail using your domain.

   Do: Get administrative access to your DNS zone and to every mail platform. Then write the list: mailbox provider, newsletter tool, CRM, invoicing/ERP, ticketing/helpdesk, e-commerce platform, HR and payroll, appointment reminders, website contact forms, monitoring and backup alerts, the scanner in the corridor that emails PDFs, and anything a department signed up for on a credit card.

   Verify: ask Finance, Marketing, HR and IT separately — they will each name a tool the others forgot. Read your current SPF record for stale include: lines.

   Risk if skipped: you will discover the forgotten sender on the day you switch to enforcement, and the thing that stops working will be payroll or invoices.

2. 1 Publish SPF — gently

   Goal — one correct SPF record that fails soft.

   Do: create a single TXT record on the domain apex listing every provider from step 0, ending in ~all. Use the record builder below. Prefer include: tokens from your vendor's documentation over hand-typed IP addresses.

   Verify: exactly one record starts with v=spf1; the recursive lookup count is ≤10; a test message shows spf=pass in Authentication-Results.

   Wait: one TTL (lower the TTL to 300 s a day before you make changes, then raise it again afterwards).

   Risks: two SPF records or >10 lookups → permerror and SPF is effectively off; going straight to -all with an incomplete list → legitimate mail rejected immediately; using mx out of habit authorises your inbound servers, which is not what you meant.

3. 2 Turn on DKIM on every platform

   Goal — every legitimate message carries a signature with d=yourdomain.

   Do: in each platform, enable DKIM / “authenticate your domain” / “branded sending”. It will give you either a TXT record or one or more CNAMEs. Publish them, wait, then press the platform's “verify” button, then enable signing.

   Verify: send a test to a Gmail address and to a Microsoft 365 address; the header must show dkim=pass and header.d=yourdomain.com. If d= shows the vendor's domain, you have enabled their shared signing, not yours — find the “custom/branded domain” setting.

   Wait: propagation, typically minutes to a few hours.

   Risks: enabling signing before DNS resolves → every message fails DKIM; leaving t=y test mode on forever; 1024-bit keys where 2048 was available; forgetting one platform, which then becomes the thing that breaks at step 6.

4. 3 Publish DMARC in monitor mode — today

   Goal — start collecting evidence. Nothing changes for anyone.

   Do: add a TXT record at _dmarc.yourdomain.com:

   v=DMARC1; p=none; rua=mailto:[email protected]; fo=1;

   Verify: the record resolves; the mailbox exists and is monitored; reports start arriving within 24–72 hours.

   Risk: essentially zero — p=none changes no delivery decision. The only real mistakes are pointing rua at a mailbox nobody reads, or at an external analyser without its authorisation record (see the DMARC section), so the reports never arrive at all.

5. 4 Read reports for two to four weeks

   Goal — a complete inventory of who sends as you, from the data rather than from memory.

   Do: feed the XML into an analyser (or a spreadsheet). Sort every source IP into the four buckets from the DMARC section. Chase down every unknown source until you can name it.

   Verify: you can account for >98% of your volume, and the remainder is low-volume noise you have consciously decided to ignore.

   Wait: at least one full monthly cycle if you have monthly processes — invoicing, payroll and annual renewals only show up when they run.

   Risk of hurrying: a sender that only fires once a month is invisible in a two-week window, and you will block your own invoices in step 7.

6. 5 Fix alignment for everything legitimate

   Goal — every source in bucket 2 either aligns or is retired.

   Do: for each failing-but-legitimate source, one of:

   • Enable the vendor's custom DKIM domain so d= becomes yours.
   • Configure a custom return-path / bounce subdomain (e.g. bounce.yourdomain.com) so SPF aligns too.
   • Move bulk or transactional mail to a dedicated subdomain (news.yourdomain.com, billing.yourdomain.com) — this isolates reputation and makes each stream easy to reason about.
   • Stop the sender: the abandoned trial account from three years ago should simply be turned off and removed from SPF.

   Verify: the source appears as aligned in the next aggregate report.

   Risk: this is where projects stall for a year. Assign an owner per sender with a date, or nothing will move.

7. 6 Ramp to quarantine

   Goal — failing mail goes to junk instead of the inbox, gradually.

   Do: tighten SPF from ~all to -all first, then step the DMARC policy over two to four weeks:

   v=DMARC1; p=quarantine; pct=25; rua=mailto:[email protected]; fo=1;
   … then pct=50 … then pct=100

   Verify: after each increase, check reports and your helpdesk queue for two to three days before increasing again.

   Tell people first: warn IT support and department heads that some mail may land in junk, and give them a single place to report it.

   Risks: legitimate mail junked (recoverable — the user can still find it); auto-forwarded mail failing SPF but usually saved by DKIM or ARC; mailing lists that rewrite subjects breaking DKIM. pct is your dimmer switch — use it.

8. 7 Go to reject

   Goal — nobody can send mail as your domain. This is the actual protection.

   v=DMARC1; p=reject; sp=reject; rua=mailto:[email protected]; fo=1;

   Do: move to p=reject once a full reporting cycle at quarantine; pct=100 is clean. Set sp=reject explicitly. Consider adkim=s; aspf=s only if every stream is exactly aligned.

   Verify: reports show near-zero failures from your own sources; spoofed traffic now shows disposition reject.

   Risks: failing mail is now bounced, not junked — unrecoverable. A newly onboarded vendor added after step 4 will break loudly. Some old-fashioned mailing lists will mangle messages beyond DKIM's tolerance; the mature ones rewrite the From address to their own domain precisely to avoid this.

   Have a rollback ready: dropping back to p=quarantine is one DNS edit plus a TTL. Keep the TTL low during the ramp.

9. 8 Lock down every domain that does not send mail

   Goal — parked, legacy and typo-defence domains cannot be abused either.

   Do: on each non-sending domain publish:

   @                 TXT  "v=spf1 -all"
   _dmarc            TXT  "v=DMARC1; p=reject; sp=reject; rua=mailto:[email protected];"
   *._domainkey      TXT  "v=DKIM1; p="
   @                 MX   0 .

   Verify: a test message from an external tool to that domain is refused, and the records resolve.

   Risk if skipped: forgotten domains are the favourite launch pad for invoice fraud, because they still carry your brand name. Also remember the domains you bought defensively and never configured.

10. 9 Harden the transport and the brand

    Goal — the surrounding controls, now that identity is solved.

    Do: enable DNSSEC at the registrar; publish MTA-STS in testing mode plus TLS-RPT, then move MTA-STS to enforce; fix reverse DNS if you run your own server; add BIMI if the marketing value justifies a VMC. Add List-Unsubscribe and one-click support to all bulk mail.

    Risk: MTA-STS in enforce with a wrong MX list will make incoming mail fail. Always run it in testing first and read the TLS reports.

11. 10 Keep it alive

    Goal — the configuration decays without maintenance.

    • Quarterly: re-count SPF lookups, remove includes for vendors you have left, review who reads the reports.
    • Every 6–12 months: rotate DKIM keys.
    • On every new vendor: SPF include + DKIM + a test before the first campaign, not after.
    • Continuously: alert on a sudden spike of DMARC failures — it is either your own change or an active phishing campaign, and you want to know which within hours.
    • Watch for lookalikes: newly registered domains resembling yours are the early warning of a targeted campaign.

    Risk if skipped: silent drift. The record still says p=reject, but a stale include pushed you past ten lookups six months ago and SPF has been in permerror ever since.

🧱 Record builder

Tick what you use and copy the records out. Everything is computed locally — nothing is sent anywhere. Always cross-check the include: value against your provider's own documentation before publishing; vendors do change them.

🔬 Record inspector

Paste an SPF, DMARC, DKIM, BIMI or MTA-STS record and get it back in plain English, with the problems flagged. Parsing happens in your browser.

⚠️ What can go wrong — and what it looks like

Almost every email authentication outage in the world is one of these. The symptom is what a user reports; the cause is what you will actually find.

🔎 Recognising a fake — the one-page version

Hand this part to colleagues. No jargon required.

Authentication-Results: mx.example.net;
   spf=pass smtp.mailfrom=sender.com;
   dkim=pass header.d=sender.com;
   dmarc=pass header.from=sender.com

✅ The working checklist

Ticks are stored in this browser only, so you can close the tab and come back.

📖 Glossary

💬 Questions people actually ask