FAQ
Answers to the questions a rollout actually raises
Straight answers to the questions that actually come up in a DMARC rollout. Every article starts with the short version, so you can stop reading as soon as you have what you needed.
- How can SPF and DKIM both pass, and DMARC still fail? DMARC doesn't check whether SPF or DKIM passed in isolation — it checks alignment: whether the domain that passed SPF or DKIM matches the domain in the visible From address. Mail sent through a third party (an ESP, a forwarder, a vendor) routinely authenticates cleanly against that third party's own domain while failing alignment against yours, which is enough on its own to fail DMARC under a p=quarantine or p=reject policy.
- How does DMARCLoop identify sources, forwarding and threats? DMARCLoop starts from what's in every aggregate report — source IP, message counts, disposition, and the SPF/DKIM results with their domains — and layers identification on top using reverse DNS, ASN lookups, and fingerprinting against known ESP IP ranges. Forwarding and unauthenticated abuse each leave a distinct signature in that data.
- How do I publish a DMARC record? Publish a TXT record at _dmarc.example.com starting with v=DMARC1; p=none, add your rua reporting address, and roll forward to quarantine and then reject only once every legitimate source is aligned. If your reporting address is on a different domain, you also need an authorization record at the destination or reports silently stop.
- How do we send DMARC-compliant email on behalf of our customers? You need SPF or DKIM to authenticate as your customer's domain, aligned with whatever domain appears in the From header — not just permission to use their name. There are three workable patterns: a per-customer Return-Path subdomain your customer CNAMEs to your infrastructure, a CNAME-delegated DKIM selector so you sign with d=customer.com, or sending from your own domain with the customer only in the friendly-From and Reply-To. Putting the customer's bare domain in From without one of these breaks DMARC for every customer who enforces a policy.
- What is DMARCbis? DMARCbis is the IETF's re-specification of DMARC, published in 2026 as RFC 9989 (core protocol), RFC 9990 (aggregate reporting), and RFC 9991 (failure reporting) — obsoleting the original RFC 7489 from 2015. It removes the `pct`, `ri`, and `rf` tags, adds `np` and `psd`, makes the external destination authorization record mandatory, and replaces Public Suffix List lookups with a DNS Tree Walk for organizational- domain discovery.
- What are MTA-STS and TLS-RPT? MTA-STS (RFC 8461) lets a domain tell sending mail servers "always use TLS with a valid certificate when delivering to me, and here are the only hostnames allowed to receive it." It closes the downgrade attack that plain opportunistic TLS leaves open. TLS-RPT (RFC 8460) is its reporting half: a TXT record naming where senders should send daily reports about TLS failures, which is the only way to find out a policy has stopped matching reality.