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 and DKIM results with their domains. It recognises a known sending service by the DKIM and SPF domains the reports show for an IP, then by the IP's reverse DNS name, never by its network (ASN) or by IP ranges. Each source is then sorted into compliant, known sender failing, forwarded, or unknown or threat, from its pass rate, the receivers' override reasons and its SPF and DKIM pattern.
- 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.
- What are the risks of moving to p=reject before every sender is identified? Under p=reject, every message that fails DMARC alignment is refused outright — and the domain owner is not told. Any legitimate sender you haven't identified and aligned yet (a billing platform, a scan-to-email copier, a vendor that sends as your domain, a subdomain nobody inventoried) stops delivering the moment the record changes, and the only evidence is a disposition=reject row in the next day's aggregate report. Moving to reject is the right destination; moving there before the inventory is complete just turns your own mail into the thing that gets blocked.
- 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.