DNS trust, part 3 of 3 · Reviewed October 24, 2026
A message can pass an authentication check and still fail DMARC. That sounds contradictory until you ask which domain passed. A newsletter service may be authorized to send for its own domain while the message shows your company’s address in the From field. Email authentication becomes much easier to troubleshoot when those identities are kept separate.
Earlier parts of this series cover DNS and DNSSEC validation and DANE authentication of a TLS server. Here, the question changes: does an email’s authenticated domain connect to the domain its reader sees?
SPF checks the sending route
Sender Policy Framework lets a domain publish which hosts may use it in SMTP identities. For normal message delivery, the relevant identity is the envelope sender, or MAIL FROM, used between mail servers. It can differ from the visible From address. A receiver compares the connecting server’s IP address with the domain’s SPF policy. SPF therefore does not, by itself, authenticate the visible author. Forwarding can change the connecting server and cause an otherwise legitimate message to fail this check. RFC 7208 explains SPF’s identities and processing.
DKIM signs selected message content
DomainKeys Identified Mail adds a cryptographic signature associated with a signing domain, identified by d=. A selector, s=, helps locate its public key in DNS. Verification checks the signature over the signed headers and body representation. A valid signature establishes the signing domain’s responsibility for that content, not the honesty of the person who wrote it. Changes to signed content can invalidate it; publishing a key alone does not prove that a particular message was signed correctly. See the DKIM specification.
DMARC asks whether the domains align
DMARC connects authentication to the domain in the visible From address. A message passes when at least one mechanism both passes and aligns: SPF with its authenticated envelope-sender domain, or DKIM with a validated signing domain. Two unrelated passing identities are insufficient. Microsoft’s alignment troubleshooting guidance illustrates this distinction.
Strict alignment requires the same domain. Relaxed alignment permits domains sharing the same organizational domain. For example, with the organizational domain established as example.com, news.example.com and example.com can align in relaxed mode, but not strict mode. The SPF and DKIM alignment settings are independent. Do not treat “relaxed” as permission to authenticate with any supplier’s domain.
The standard changed in 2026
RFC 9989, published in May 2026, replaces RFC 7489 for the core protocol. Aggregate reporting and failure reporting now have separate specifications. The update also replaces the old organizational-domain discovery approach with a DNS tree walk and removes pct. Check software behavior before copying older rollout recipes.
The policy values remain p=none, p=quarantine and p=reject: no requested DMARC-specific action, suspicious treatment, or rejection preference. Crucially, RFC 9989 says receivers must not reject solely because of p=reject; additional analysis is required, otherwise failing mail is treated as quarantine. Published standards and deployed behavior can differ, so verify actual delivery rather than assuming a universal result.
Read reports before tightening policy
Aggregate reports under RFC 9990 summarize sending sources, authentication results and handling. Use them to compare your expected senders with what receivers observe. An unfamiliar source needs investigation: it might be abuse, a forgotten application or a forwarding path. Reports are evidence to analyze, not a complete inventory automatically certified as legitimate.
RFC 9991 failure reports concern individual failed messages or similar failures. They can expose message headers and sometimes content, including personal information. Decide who should receive them and how they will be protected before requesting them. A request also does not guarantee that every receiver will send a report.
A practical review, without changing DNS yet
- List sending services. Include support desks, billing systems and marketing platforms, not just employee mailboxes.
- Inspect representative messages. Compare the visible From domain, envelope-sender domain, DKIM signing domain and your trusted receiving service’s authentication results.
- Check real delivery paths. Include forwarding and mailing lists. RFC 9989 specifically warns against relying solely on SPF when publishing
p=reject. - Investigate before enforcing. Separate configuration failures from unauthorized use, and retain a clear recovery plan for legitimate mail.
DMARC does not encrypt email or stop all phishing. Lookalike domains and compromised accounts remain risks. Authentication of a domain is evidence for a receiver, not a guarantee that the message is safe. See DMARC’s anti-phishing scope.
The SysSeder DNS Inspector provides a starting view of public mail configuration, including basic SPF checks, a directly published DMARC policy and a DKIM record for a selector you supply. It does not evaluate a full SPF sending path, discover inherited DMARC policy through a tree walk, or validate a message’s DKIM signature. Read the coverage and unknowns alongside its findings.