Why DMARC?
SPF and DKIM each check only one technical detail: is the IP allowed (SPF)? Is the signature valid (DKIM)? Neither says anything about whether the sender address the recipient sees matches the domain being checked. That is exactly where DMARC steps in.
Example record
; TXT record for _dmarc.firma.at "v=DMARC1; p=reject; rua=mailto:[email protected]; pct=100; adkim=s; aspf=s"
The most important parameters:
| Tag | Meaning |
|---|---|
p= | Policy: none, quarantine or reject. |
rua= | Address for aggregate reports (daily statistics). |
ruf= | Address for forensic reports (individual failed messages). |
pct= | What percentage of mail the policy is applied to. |
adkim / aspf | Alignment strictness: s=strict, r=relaxed. |
The three policies
| Policy | Effect | Use |
|---|---|---|
p=none | Observe only — reports, no action. | Start |
p=quarantine | Suspicious mail goes to the spam folder. | Stage 2 |
p=reject | Suspicious mail is rejected outright. | Target |
How it fits together — an analogy
Picture a visit to an embassy:
- SPF is the fence around the grounds — who is allowed in at all.
- DKIM is the seal on the letter — proof that it has not been opened.
- DMARC is the protocol officer — checks that the fence and seal actually match the person on the envelope. And tells the guard what to do if something does not line up.
none straight to reject is risky. Without report analysis you risk blocking legitimate mail (forgotten newsletter tools, old CRMs). The DMARC policy guide shows the safe path.Using reports properly
The aggregate reports (via rua) arrive daily from Google, Microsoft, Yahoo & co. as XML files. They list which IPs have been sending in your name — including any that fail SPF or DKIM. That is gold for spotting shadow IT and phishing attempts.