Guide
Email authentication is a set of DNS-published standards that let a receiving mail server verify that a message genuinely came from the domain it claims. SPF authorizes which servers may send for a domain. DKIM cryptographically signs the message so tampering is detectable. DMARC ties the two to the visible From address and tells receivers what to do when authentication fails. BIMI displays a verified brand logo once DMARC is enforced. This page covers how the four fit together, the alignment rule that most explanations skip, what the 2026 DMARC revision changed, and where DKIM2 really stands.
Last reviewed September 2026
The four standards
The fourth column is the one to read. Each standard answers exactly one question, and every common authentication failure comes from assuming one of them answers a question it does not.
| Standard | What it verifies | Where it lives | What it does not do |
|---|---|---|---|
| SPF | That the server handing over the message is one the envelope sender domain, the Return-Path, has listed as permitted to send for it | A TXT record at the domain itself, beginning v=spf1 | Says nothing about the From address the recipient sees, so it cannot stop spoofing on its own. Breaks when mail is forwarded, and fails with a permanent error once the record needs more than ten DNS lookups |
| DKIM | That the message was signed by a party holding the private key for the signing domain, and that the signed headers and body have not changed since | A public key in a TXT record at selector._domainkey.domain; the signature itself travels in the message header | Does not by itself tie the signing domain to the visible From address. A valid signature from an unrelated domain still passes DKIM |
| DMARC | That an SPF or DKIM pass is for a domain aligned with the visible From domain, and publishes what the domain owner wants done with messages that fail | A TXT record at _dmarc.domain, beginning v=DMARC1 | Authenticates nothing on its own. It depends entirely on SPF and DKIM, and a pass makes a message attributable, not trustworthy |
| BIMI | That the domain owner has asked for a brand logo to be displayed, and where the logo and its supporting evidence can be fetched | A TXT record at default._bimi.domain, and the SVG logo file it points to | Not an authentication method. It is a display feature that supporting mailbox providers unlock only when DMARC passes under an enforcement policy |
Kept deliberately short. The depth on each protocol belongs on its own page; what this page needs is enough of each to make the alignment section make sense.
Sender Policy Framework, defined in RFC 7208, is a TXT record at the domain in the envelope sender address, the Return-Path that the recipient never sees. The record lists the IP addresses and hostnames permitted to deliver mail for that domain, usually by pulling in other records with include:. A receiving server looks up the record for the Return-Path domain and checks whether the connecting IP is in it.
Two properties follow from that design and cause most of the trouble with SPF. The first is that it evaluates the Return-Path, not the From header, so a message can pass SPF while showing the recipient any From address at all. The second is that the standard caps evaluation at ten DNS-querying mechanisms; an eleventh produces a permanent error, and the failure is not visible until somebody adds one more include: to a record that has been quietly accumulating them for years.
On Omnivery the Return-Path is constructed on your sending domain for every message, so SPF passes and aligns without the record being your problem. Which servers are permitted is Omnivery's to maintain.
DomainKeys Identified Mail, RFC 6376, adds a signature to the message header. The signing domain and a selector name are in the signature, and the public key sits in DNS at selector._domainkey.domain. A receiver fetches the key and checks the signature over the body and the chosen headers. A pass proves two things: the signer holds the private key for that domain, and the signed content is what the signer saw.
DKIM generally survives forwarding, which SPF does not, because the signature travels with the message rather than depending on the connecting IP. What DKIM does not do is connect the signing domain to the From address. A message signed validly by one domain and showing another in From passes DKIM, and that gap is precisely what DMARC exists to close.
Omnivery signs every outgoing message with your sending domain's key. The DKIM records you publish are CNAMEs, so keys can be rotated without a record change on your side.
Domain-based Message Authentication, Reporting, and Conformance is now defined by RFC 9989, with reporting in RFC 9990 and RFC 9991. A DMARC record at _dmarc.domain does two things. It requires that at least one of SPF or DKIM passes and is for a domain aligned with the From domain, the rule the next section is about. And it publishes a policy for messages that fail: p=none to monitor only, p=quarantine to have them treated as suspicious, p=reject to have them refused. Aggregate reports sent to the address in the rua tag tell the domain owner who is sending as them and whether it authenticates.
Two things about DMARC are routinely overstated. The published policy is a request rather than an instruction: RFC 9989 is explicit that final handling is the receiver's local decision, and that a receiver should not reject a message solely because the sending domain published p=reject. And a DMARC pass says only that the use of the domain was authorized by whoever controls it. It is a statement about attribution, not about whether the message is wanted.
Since February 2024 Google requires anyone sending 5,000 or more messages a day to Gmail to publish a DMARC record, though it allows the policy to be none, and requires the From domain to align with either the SPF or the DKIM domain. Yahoo requires the same of bulk senders: SPF and DKIM, a DMARC record with at least p=none that passes, and an aligned From domain, with relaxed alignment accepted. Yahoo does not publish a daily message count that makes a sender bulk, so the safe reading is that the requirement applies to you. Omnivery required all of that before either rule was announced.
The none in both requirements is the current floor, not the destination. A policy of none asks receivers to do nothing with failures, so a domain that stops there has published a monitoring address and protected nothing. Mailbox providers have moved from recommending DMARC to requiring it in under a decade, and the direction of the next step is not in doubt. Our position is that every customer should get their sending domains to an enforcement policy now, on their own schedule, rather than when a provider announces a deadline. Enforcement reached under time pressure is where legitimate mail gets rejected.
Brand Indicators for Message Identification lets a domain publish a record at default._bimi.domain pointing to an SVG logo and, where required, to a certificate vouching for it. Mailbox providers that support BIMI display the logo next to the message. The specification is an Internet-Draft rather than an RFC, and it sets hard preconditions: the message must pass DMARC, the applicable policy must not be none, and if the policy is quarantine with a percentage tag, that tag must be 100.
That makes BIMI a consequence of authentication rather than a component of it. A domain that cannot get to an enforcement policy cannot get a logo, and a domain whose DMARC breaks loses the logo along with everything else. It is also worth knowing that the BIMI draft, at revision 14 from May 2026, still cites the superseded DMARC RFC; the specifications in this area do not all move at once.
Passing SPF or DKIM is not enough on its own, and this is the single point where "we have authentication set up" most often turns out to be untrue. DMARC requires the domain that was authenticated to align with the domain in the visible From header, the one the recipient reads. RFC 9989 calls this identifier alignment, and it is evaluated separately for each mechanism:
DMARC passes if at least one of the two is both authenticated and aligned. It fails if neither is, however many individual checks passed along the way.
Each alignment comes in two modes, chosen by the domain owner in the DMARC record with the aspf and adkim tags, and both default to relaxed.
unique-id@news.example.com aligns with a From address of info@example.com, because both resolve to example.com.news.example.com must equal news.example.com; the parent domain is not close enough.The goal is full alignment: SPF aligned and DKIM aligned, not one or the other. RFC 9989 is direct about why the DKIM half matters most. Forwarded mail and mailing lists usually break SPF, because the forwarding server's IP is not in the original domain's record, while DKIM signatures generally survive the trip. The standard therefore says that a domain publishing p=reject must not rely on SPF alone and must apply valid DKIM signatures.
The classic failure is a third-party platform sending on your behalf with its own domain in the Return-Path. SPF passes, for the platform's domain. DKIM passes, signed by the platform's domain. Your From address shows your domain. Neither authenticated identifier aligns with it, so DMARC fails, and if your policy is quarantine or reject, your own mail is the mail being filtered. Every check that anyone looked at individually was green.
Omnivery checks the domain alignment of every message on both API and SMTP submission. If the From address is not within the domain space of your sending domain, the message is not accepted.
The Return-Path is built on your sending domain and the DKIM signature uses your sending domain, so both identifiers align by construction. How that works, including using a subdomain such as news.example.com as the sending domain while showing info@example.com in From, is in the domain setup documentation. A domain can be set as a wildcard to permit one additional level of subdomain in the From address; the domain detail documentation covers that setting.
One more thing changed about alignment in 2026, and it is easy to miss because it looks like a policy-lookup detail. The Organizational Domain that relaxed alignment depends on is no longer determined the way it used to be. That is the next section.
In May 2026 the IETF published three Standards Track RFCs that together replace RFC 7489, the document DMARC had run on since 2015. Most pages explaining DMARC still cite the old one.
rua address.ruf address.The set is known as DMARCbis. It is also the first time DMARC has carried formal IETF endorsement. RFC 7489 was not the product of an IETF working group; it went into the RFC series through the Independent Submissions Editor as an Informational document. RFC 9989 is on the Standards Track, and it also retires RFC 9091, the experimental extension for policies published by public suffix operators, whose mechanism it absorbs.
Records still begin with v=DMARC1. There is no "DMARC2", and an existing record remains valid. The version tag was left alone on purpose.
This is the change that matters, and it is the one explained least often.
Under RFC 7489, working out a domain's Organizational Domain, the registered domain that subdomains roll up to, meant consulting the Public Suffix List, a file maintained outside the standard at publicsuffix.org. RFC 7489 never mandated which list receivers should use or how often they should refresh it, and acknowledged that receivers choosing different lists could reach different answers.
RFC 9989 replaces the list with a lookup receivers perform in DNS itself. Starting at the domain in question, the receiver queries for a _dmarc record, then strips the leftmost label and queries again, walking up the hierarchy until it finds records and can pick the Organizational Domain from them. To stop an attacker forcing unbounded lookups with a From domain of fifty labels, the walk is capped at eight DNS queries: domains with more than eight labels are shortened before the walk begins.
The Organizational Domain is used for two things, and only one of them is about finding the policy. It locates the applicable DMARC record when the From domain has none of its own. And it is what relaxed identifier alignment is evaluated against. Two domains are relaxed-aligned when they share an Organizational Domain, so changing how that domain is determined changes whether a message passes.
Because the Tree Walk and the Public Suffix List can resolve the Organizational Domain differently, a receiver running RFC 9989 can reach a different alignment conclusion than one still running RFC 7489 for the same message. RFC 9989 says so itself, in its own summary of changes: a domain owner expecting the Tree Walk to identify a record or an Organizational Domain may find a receiver still relying on a list "might arrive at a different answer". For a flat setup with one domain and one sending subdomain, the two methods agree. For deep subdomain hierarchies, delegated zones and domains under unusual suffixes, they may not.
The mitigation is stated in the standard and is worth following regardless of which receivers you send to: publish an explicit DMARC record at every domain and subdomain you send from, and prefer strict alignment. RFC 9989 describes that combination as avoiding the ambiguity entirely.
A record at the exact From domain is always queried first, before any walk begins, so a receiver on either version finds the same record and applies it. It also removes the case RFC 9989 warns about for organizations with long subdomain chains, where a record published deeper than eight labels is never reached by the walk and has to be published at the sending name itself.
The guidance on enforcement is more careful than the folk version. RFC 9989 keeps the interoperability warning from its predecessor and sharpens it: mail from a domain with p=reject that passes through a mailing list or a forwarding alias is frequently rejected, and the standard says domains hosting users who post to mailing lists should not publish p=reject. Domains that want to should spend at least a month at p=none and an equal period at p=quarantine, comparing report data before moving. On the other side, receivers are told not to reject solely on the basis of a published p=reject and, absent other analysis, to treat such failures as quarantine. None of that is advice against enforcement for a domain that sends only its own transactional and marketing mail through infrastructure it controls. It is a description of what enforcement does to mail that takes an indirect route.
A page citing RFC 7489 as the DMARC specification is citing a document that has been obsolete since May 2026, and much of the validation tooling on the market was written against it. Being current here is not a stylistic preference. It is the difference between describing how the standard evaluates alignment and describing how it used to.
Tag changes
Nothing breaks if a removed tag is still in a record. RFC 9989 keeps the rule that unknown tags must be ignored, so a receiver on the new standard skips pct and moves on. New records should leave the removed tags out and use the new ones where they apply.
| Tag | Status in RFC 9989 | What it does, or did | Why |
|---|---|---|---|
pct | Removed | Asked receivers to apply the policy to only a percentage of failing messages, as a way of ramping from none to quarantine to reject | Operational experience showed it was applied inaccurately at any value other than 0 or 100, and the inaccuracy varied between implementations. The one useful behavior, pct=0, survives as the t tag |
rf | Removed | Requested a format for failure reports | Failure reporting moved wholesale into RFC 9991, and the tag went with the old text |
ri | Removed | Requested an interval between aggregate reports | Aggregate reporting moved into RFC 9990, which describes reports as daily or more frequent. The ability to request a maximum report size in the reporting address was removed at the same time |
np | Added | A policy for subdomains that do not exist in DNS, separate from the sp policy for subdomains that do | Closes a long-standing gap: mail from a made-up subdomain of a real domain previously fell under whatever the general subdomain policy happened to be. Imported from RFC 9091 |
psd | Added | Marks a domain as a Public Suffix Domain (psd=y), or declares that it is its own Organizational Domain (psd=n) | Gives the Tree Walk a stopping point. Relevant to operators of suffixes such as .bank, and to large organizations that want a delegated subtree treated as its own organization |
t | Added | Test mode. t=y asks receivers not to apply the published policy and to treat failures one level down, so reject acts as quarantine and quarantine acts as none. t=n, the default, means apply it | Replaces the only part of pct that worked. Reports are still generated in test mode, so a domain owner can see the effect of a policy before it applies |
RFC 9989 section 4.7 for the tag definitions, Appendix C.5 for the list of tags added and removed, Appendix A.6 for the history of pct and Appendix C.4 for the reporting changes.
DKIM2 gets written about with more enthusiasm than accuracy, so this section is deliberately flat. Everything in it is checked against the working group's own documents as of September 2026.
draft-ietf-dkim-dkim2-spec-06, dated 28 August 2026, edited by engineers at Yahoo, Google and Fastmail, with an intended status of Standards Track. It replaces an earlier individual draft and has been revised six times since the working group adopted it.DKIM signs a message once, at the origin. DKIM2 has every system that handles the message add a signature of its own, numbered in sequence, so the message carries a chain from the originator through each forwarder to the final receiver. The draft calls this the Chain of Custody. Each signature records the envelope addresses used at that hop, the MAIL FROM and the RCPT TO values, and a verifier checks that the chain is plausible.
That structure addresses two problems DKIM cannot.
Two smaller points follow from the chain. Delivery status notifications, the bounces covered in the bounces guide, can be routed back only to systems that were actually part of the message's path, which removes a class of backscatter. And a system in the chain can ask for feedback, such as whether the eventual recipient marked the message as spam.
On 4 July 2026 the working group's mailing list carried interoperability results from three independent implementations: a Rust library, a Python implementation and a Go implementation, written by different people. With header folding disabled, every combination agreed on signing, verifying and recipe-based reconstruction across all three. Folded headers exposed parsing differences that were then fixed. That is what moving from a paper design to a demonstrable protocol looks like, and it is also a reminder that the protocol is still being debugged.
The pace is unusual for an IETF document, and the reason is who is behind it. The draft is edited by engineers at Yahoo, Google and Fastmail, and there is a significant push from mailbox providers to get the specification finished and approved as soon as possible, because the replay problem it closes is theirs to live with. That backing is why the working group has produced six revisions in well under a year. It does not amount to a published date, and there is none, but it does mean the usual assumption that a draft will drift for years does not apply here. Our own expectation is that receivers begin testing DKIM2 against live mail by the end of 2026.
DKIM2 is the designated successor to ARC as well. ARC, RFC 8617, was published in 2019 as an Experimental protocol meant to preserve authentication results across forwarders. On 22 April 2026 the IETF DMARC working group adopted a draft, draft-ietf-dmarc-arc-to-historic, calling for the experiment to be concluded and ARC reclassified as Historic, on the grounds that it saw neither noteworthy uptake nor sufficient impact. The same document states that the experience gained is being incorporated into DKIM2 as the successor to DKIM. RFC 9989 makes the same observation in passing: none of the methods for letting mailing lists work without rewriting From have become widely used.
Nothing, yet. DKIM2 keys are published in the same place as DKIM keys: the draft states that they "are no different, and are stored in the same locations" under _domainkey. Existing selectors and records remain valid. The work of implementing DKIM2 sits with the systems that sign and verify, which for a sender using a platform means the platform.
One disambiguation, because the confusion is common. Microsoft's Azure Communication Services portal labels its two DKIM CNAME records "DKIM" and "DKIM2", the second being a second selector, selector2, used for key rotation. That is an interface label for a standard DKIM record. It has nothing to do with the IETF DKIM2 protocol.
Omnivery's position is that support for DKIM2 is planned and is being prepared now, so that it can be rolled out when the specification settles or receivers begin testing against it, whichever comes first. On our reading that is months away rather than years. It is not available today and no launch date is being given, because the standard does not have one either. What can be said is structural: a platform that already signs every message, validates every domain and re-checks authentication continuously is the kind of platform that adopts a new signing standard as a deployment rather than a project. The reasoning behind meeting requirements before they are required is set out on the deliverability page.
Most guidance treats authentication as configuration. Publish the records, run a checker, see green, done. That model has a flaw that has nothing to do with the standards: DNS is mutable and organizations are messy. The records that passed the check are not the records that will exist in six months.
Authentication drifts, and it drifts silently. The ways it happens are mundane:
include: for each new tool the marketing team adopts, until the eleventh DNS lookup turns every evaluation into a permanent error._dmarc record looks like clutter to anyone who does not know what it is.None of these produce an alert. There is no error at the moment of the change, because DNS accepts whatever it is given. The sender finds out when mail starts landing in spam, or when a DMARC aggregate report shows a spike in failures, or when a customer forwards a complaint. That is days or weeks after the change, and after the receiving side has already started adjusting its view of the domain. By the time the symptom is visible, the reputational cost has been paid.
A one-time check answers one question: was the configuration correct at the moment of the check. It says nothing about whether it is correct now. The only way to know that is to keep asking, and the only way to keep asking reliably is for something other than a person to do it.
The previous section is a general warning. This is what turns it into something a sender does not have to think about.
The payoff is a change of category. Continuous checking turns authentication from a configuration task the customer has to remember, and has to remember on behalf of every colleague with DNS access, into a property of the platform. You do not have to notice that something broke. The records you need, and the setting that lets a subdomain send for its parent, are documented under domain setup and domain detail.
At a glance
Questions
A set of standards, all published through DNS, that let a receiving mail server check whether a message genuinely came from the domain it claims to come from. SPF lists which servers may send for a domain. DKIM signs the message so that the signing domain and the integrity of the content can be verified. DMARC ties those two results to the From address the recipient sees and publishes the domain owner's wishes for messages that fail. BIMI sits on top and displays a brand logo once DMARC is enforced. Without authentication a receiver has no reliable way to attribute a message to a domain, which is why unauthenticated mail is increasingly filtered or refused outright.
They answer three different questions. SPF asks whether the server delivering the message is one the Return-Path domain has authorized, and it checks that against a TXT record at the domain. DKIM asks whether the message was signed by someone holding the private key for the signing domain and whether the signed content is unchanged, and it checks that against a public key in DNS. DMARC asks whether either of those passes was for a domain that aligns with the visible From domain, and if not, what the domain owner wants done about it. SPF and DKIM authenticate; DMARC connects the authentication to the address people actually read and adds a policy.
Yes, and in practice the large receivers now require it. Google's sender guidelines require SPF or DKIM from every sender and SPF, DKIM and DMARC from anyone sending 5,000 or more messages a day to Gmail. Yahoo requires SPF, DKIM and a passing DMARC record with at least p=none from bulk senders, and does not publish the volume at which a sender becomes one, so assume it applies. Both currently accept a policy of none; treat that as the floor, because the requirement is moving toward enforcement and a domain that reaches it early does so without a deadline. Beyond the requirements, the three are not redundant. SPF fails on forwarded mail. DKIM survives forwarding but does not tie the signature to the From address. DMARC needs at least one of them to pass and align, and RFC 9989 says a domain with an enforcement policy must not rely on SPF alone. Omnivery requires all three before a sending domain becomes active.
The requirement that the domain SPF or DKIM authenticated matches the domain in the visible From header. SPF alignment means the Return-Path domain matches the From domain. DKIM alignment means the signing domain in the DKIM signature matches the From domain. DMARC passes when at least one mechanism is both authenticated and aligned. It is the step that turns "some server somewhere was allowed to send this" into "the domain the recipient sees vouched for this", and it is the step most often missing when someone says authentication is set up.
How close a match has to be. Relaxed alignment, the default, is satisfied when the two domains share the same Organizational Domain, so a Return-Path on news.example.com aligns with a From address on example.com. Strict alignment requires the domains to be identical, so news.example.com aligns only with news.example.com. The domain owner selects the mode in the DMARC record with the aspf and adkim tags. Strict alignment is the more conservative choice and, since RFC 9989, also the one that avoids any disagreement between receivers over how the Organizational Domain is determined.
Yes, and it is common. SPF passing means the delivering server was authorized by the Return-Path domain. If that domain is not aligned with the From domain, the pass does not count toward DMARC. The typical case is a third-party platform that sends with its own domain in the Return-Path: SPF passes for the platform's domain, DKIM passes signed by the platform's domain, the From header shows your domain, and DMARC fails because nothing aligned. On Omnivery the Return-Path and the DKIM signature both use your sending domain, so this case does not arise.
Brand Indicators for Message Identification is a record at default._bimi.yourdomain that points to an SVG logo and, where a mailbox provider requires it, a certificate vouching for the logo. Supporting mailbox providers display the logo alongside messages from the domain. DMARC at enforcement is a hard precondition: the BIMI specification says processing must not happen if DMARC does not pass, if the applicable policy is none, or if a quarantine policy is published with a percentage tag below 100. So BIMI is not an authentication method, it is a reward for having authentication in order, and it disappears the moment DMARC breaks.
A proposed successor to DKIM being developed in the IETF DKIM working group. Where DKIM signs a message once at the origin, DKIM2 has every system that handles the message add a signature of its own, recording the envelope sender and recipients used at that hop, so the message carries a verifiable chain from originator to final receiver. That lets a receiver detect a replayed message, because a copy sent to recipients who were not in the chain no longer matches, and lets forwarders and mailing lists record their modifications as recipes so earlier signatures can still be verified. It is intended to replace DKIM, and the IETF is retiring ARC on the basis that its lessons are going into DKIM2.
No. As of September 2026 DKIM2 is an active Internet-Draft, draft-ietf-dkim-dkim2-spec-06 dated 28 August 2026, with no published RFC and no announced timeline for one. Three independent implementations, in Rust, Python and Go, demonstrated interoperability on the working group's mailing list in July 2026, so the protocol is real and testable, but no major mailbox provider requires or enforces it yet. The draft is edited by engineers at Yahoo, Google and Fastmail and mailbox providers are pushing to get it approved quickly, so it is moving faster than most IETF work; Omnivery expects receivers to begin testing against live mail by the end of 2026, though that is our expectation and not a published date. Omnivery is preparing support and plans to roll it out when the specification settles or receivers begin testing against it. It is not available on the platform today.
Not at the moment. The draft states that DKIM2 keys are stored in the same DNS location as DKIM keys, under _domainkey, and are no different from them, so existing selectors and records remain valid. The work of producing and verifying DKIM2 signatures belongs to the mail systems in the path, which for a sender using a platform means the platform. The useful preparation is the same as for everything else on this page: have SPF, DKIM and DMARC published, aligned and monitored, so that when a new signing standard arrives it is a deployment rather than a cleanup.
No. Microsoft's Azure Communication Services portal labels its two DKIM CNAME records "DKIM" and "DKIM2". The second is a second selector, selector2, provided so that keys can be rotated without downtime. Both records are ordinary DKIM under RFC 6376. The label is a Microsoft interface convention and has no connection to the IETF DKIM2 protocol. If you have added a "DKIM2" record for Azure, you have configured a second DKIM key, nothing more.
DMARCbis is the name for the May 2026 revision of DMARC, published as three Standards Track RFCs: RFC 9989 for the core protocol, RFC 9990 for aggregate reporting and RFC 9991 for failure reporting. Together they obsolete RFC 7489. The largest change is that the Organizational Domain is now determined by a DNS Tree Walk rather than the Public Suffix List, which affects alignment as well as policy lookup. The pct, rf and ri tags were removed and np, psd and t were added. The interoperability guidance around p=reject was sharpened. Records still begin with v=DMARC1, and DMARC is now formally an IETF standard where RFC 7489 was an Informational independent submission.
The Tree Walk is the procedure RFC 9989 defines for finding a domain's Organizational Domain: query DNS for a _dmarc record at the domain, then at each parent in turn, up to a maximum of eight queries, and select the Organizational Domain from the records found. It replaced the Public Suffix List because the list was maintained outside the standard, RFC 7489 never said which version receivers should use or how often to refresh it, and different receivers could reach different answers. The Tree Walk keeps the decision inside DNS, where the domain owner controls it, and lets large organizations declare an internal subtree as its own Organizational Domain with the psd tag.
Existing records remain valid, still begin with v=DMARC1, and any removed tag left in a record is ignored under the rule that unknown tags must be ignored. Two things are worth doing anyway. Remove pct, rf and ri from any record you edit, and use t=y in place of pct=0 if you were using that to test. And publish an explicit DMARC record at every domain and subdomain you send from, which RFC 9989 identifies, along with strict alignment, as the way to avoid receivers on different versions of the standard reaching different conclusions about your mail.
Three. pct, which asked receivers to apply the policy to a percentage of failing messages and was found in practice to be applied inaccurately at any value other than 0 or 100. rf, which requested a format for failure reports. And ri, which requested an interval between aggregate reports. The reporting tags went when reporting was moved into its own two documents. The one behavior of pct that proved valuable, pct=0 as a test signal, survives as the new t tag. Receivers must ignore tags they do not recognize, so a record still carrying the old tags does not break.
It sets a policy for subdomains that do not exist in DNS. DMARC already had sp for subdomains, but that applied to existing and non-existent subdomains alike. np lets a domain owner say that mail from a subdomain that does not resolve at all, which is a common spoofing pattern because there is nothing there to authenticate, should be treated more strictly than mail from real subdomains that may still be getting their records in order. Its values are the same as p: none, quarantine or reject. If np is absent, sp applies, and if sp is absent too, p applies.
Yes, during the transition. A receiver running RFC 9989 determines the Organizational Domain by Tree Walk; one still running RFC 7489 uses the Public Suffix List. For most domains they agree, but for deep subdomain hierarchies, delegated zones and domains under unusual suffixes they can differ, and because relaxed alignment is evaluated against the Organizational Domain, the alignment result can differ too. RFC 9989 acknowledges this in its summary of changes. The fix is in the same passage: publish explicit DMARC records for every sending domain and use strict alignment, which removes the dependency on how the Organizational Domain is derived.
Easily, and without any warning at the time. A DNS record gets edited during unrelated work, a domain moves to a new registrar and a record does not come with it, a DKIM key is rotated by a team that did not tell the platform signing with it, an SPF record collects one include too many and crosses the ten-lookup limit, a BIMI certificate expires, or someone deletes TXT records they do not recognize. DNS accepts all of it silently. The sender finds out when mail lands in spam or a DMARC report shows failures, typically days or weeks later. A check that ran once at setup tells you nothing about any of this.
Often enough that a break is caught before receivers notice it, which rules out once at setup and rules out anything a person has to remember to do. Omnivery re-checks every sending domain's authentication records multiple times per day, continuously, alongside its CAA and MX records and BIMI status, and validates alignment on every message at submission. The point is not the frequency in itself but that the checking is done by the platform rather than by whoever last had DNS open, so a change made by anyone in the organization is detected regardless of whether they knew what the record was for.
A Certification Authority Authorization record, defined in RFC 8659, is a DNS record in which a domain owner names the certificate authorities permitted to issue TLS certificates for the domain. A record at the registered domain applies to every subdomain that has no record of its own, and a CA must refuse to issue where it is not named. It is not an email authentication standard and receivers do not consult it when evaluating a message. It matters to email delivery anyway, because a sending platform serves things on your domain. On Omnivery, open tracking, click tracking and unsubscribe processing run on a tracking hostname under your domain, over TLS, with certificates issued by Let's Encrypt. A CAA record at your apex that does not permit Let's Encrypt blocks those certificates, and the first symptom is tracked links and unsubscribe pages failing. Omnivery checks the CAA record to confirm the domain owner permits issuance, and flags it before that happens. The fix is one additional CAA record naming Let's Encrypt, either at the apex or at the tracking hostname itself.
Every external claim on this page traces to one of these. Statements about Omnivery's own platform link to the relevant documentation where they are made, rather than being listed here.
Internet-Drafts change and expire. The DKIM2, ARC and BIMI drafts cited here are the revisions current in September 2026; the datatracker links above resolve to whatever revision is current when you read this, so check the revision number before quoting. No figure is claimed for DKIM2 adoption, for the number of receivers running RFC 9989, or for how often Omnivery's checks run beyond multiple times per day.
Authentication decides whether a receiver can attribute a message to your domain at all. These cover what the receiver does with that attribution, and the parts of the configuration that sit next to it.
SPF, DKIM and DMARC required before a domain sends, alignment enforced on every message, and every record re-checked multiple times a day against the current standard rather than the superseded one. BIMI, CAA and MX status visible in the same place. When DKIM2 settles, it will be a deployment, not a project.