Domain authentication protocols (SPF, DKIM) are evaluated by receiving servers, but they are hard to monitor on their own. That is the gap DMARC fills: it lets you monitor authentication and alignment for every sending source against the sending domain. In May 2026, DMARC was updated to a new standard. Are you ready?
What is DMARC? Listen to the article (Audio is auto-generated)
Important update: In May 2026, the IETF published a new DMARC standard (DMARCbis), replacing the 2015 specification (RFC 7489).
This article is updated to align with the new standard. Pay attention to the deprecated tags (pct, rf, ri) and the new tags (np, t, psd).
A Q&A section appears at the end of the article.
—
In a world where we are exposed to ten thousand or more marketing messages every day, distinguishing fake from real only gets harder.
This is where email stands out from other direct communication channels: it includes built-in mechanisms for authenticating the sending domain, evaluated at the operator level (mailbox providers, receiving email servers, spam filters, phishing filters, and other security layers).
These mechanisms do not exist in a built-in, operator-level form for phone calls, SMS, or in several instant messaging channels, making those channels more vulnerable and easier to spoof.
To make email safer, a series of protocols were developed over the years to authenticate the sending domain and are evaluated by receiving servers (SPF, DKIM), along with visual indicators that recipients can recognize (BIMI).
Together, these measures give email its standing as the most trusted channel in customers’ eyes.
That said, domain authentication does not guarantee reaching the inbox. Correct domain authentication is the entry ticket to deliverability.
What Is DMARC?
The DMARC protocol is designed to protect domains and brands against spoofing and to monitor SPF and DKIM configurations.
DMARC is not a domain authentication protocol. The authentication protocols SPF and DKIM verify the sender’s identity in different ways:
SPF – defines the IP addresses and networks authorized to send on behalf of a domain.
DKIM – cryptographically signs portions of the message to verify it was not modified in transit between sender and recipient.
These protocols are difficult to monitor on their own, and that is the gap DMARC fills.
DMARC stands for Domain-based Message Authentication, Reporting & Conformance.
A DMARC policy lets the Domain Owner instruct mailbox providers and spam filters on how to handle messages that fail authentication or do not align with the sending domain as defined by SPF and DKIM.
In addition, DMARC provides Aggregate Reports and Failure Reports, sent by receiving mail servers (Gmail and others), giving the sending side data on how the receiving side sees its email traffic. Reporting includes authentication status (valid SPF / DKIM), alignment status (aligned SPF / DKIM), and other important data points.
Under the new standard: for DMARC purposes, SPF is evaluated strictly against the MAIL FROM identity (also known as return-path or envelope sender), with no fallback to the HELO identity. For most senders, this is transparent, but if your infrastructure relied on HELO evaluation, verify.
The New Standard: Three RFC Documents Instead of One.
The original specification, RFC 7489, was published in 2015 as a single document with only Informational status. That document is now obsolete.
The new standard, published in May 2026, is split into three separate documents on the Standards Track as a Proposed Standard:
RFC 9989 – The protocol itself: policy discovery, SPF and DKIM alignment evaluation, and how a Mail Receiver should behave. This document also absorbs RFC 9091 (the psd tag), which is now obsolete.
RFC 9990 – Aggregate Reporting: the XML schema, how report destinations are discovered and verified, and how reports are transmitted.
RFC 9991 – Failure Reporting: per-message reports, with a stronger emphasis on privacy.
DMARC’s move from Informational to the Standards Track is not just semantics. It means mailbox providers worldwide will interpret and implement the protocol more consistently, and regulators and frameworks such as PCI DSS and NIS2 can now cite an official internet standard.
And what about your DMARC record?
Although the standard was updated (some call it “DMARC 2.0” or “DMARCBis”), the DNS record still begins with v=DMARC1, and backward compatibility remains complete. What changed is detailed below.
New – DNS Tree Walk Replaces the Public Suffix List
A significant technical change in the new standard. Until now, when a Mail Receiver needed to determine a message’s Organizational Domain, it relied on the Public Suffix List – an externally maintained list (historically operated by Mozilla), updated manually with delays, and never designed for email authentication.
The new standard replaces the PSL with an algorithm called the DNS Tree Walk: the mail receiver queries the DNS directly. It looks for a DMARC record at the domain the message was sent from.
If none exists, it climbs the hierarchy label by label (for example: welcome.example.com, then example.com, then com), up to a maximum of eight levels. The first record found is authoritative. The DNS is the source of truth, and the new standard queries it directly, reflecting how commonly email is sent from subdomains.
DMARC became mandatory
Despite common assumptions, properly deploying a DMARC policy holds significant value, even if your SPF and DKIM are correctly set up.
On DMARC implementation mistakes and FAQ, see below.
Since 2024, under the major mailbox providers’ “New Sender Guidelines” (remember Yahoogle?), a valid DMARC record has been mandatory for bulk senders.
A bulk sender is anyone who sends 5,000 or more emails per day to Gmail (other major mailbox providers treat bulk senders similarly), which makes even owners of relatively small lists bulk senders by definition. For example, if you have a list of 1,800 recipients and during a special sales week you sent three campaigns to the entire list on the same day, you crossed the threshold: as far as Gmail and the other major providers are concerned, you are now a bulk sender (congrats!) – even if you crossed the 5,000-per-day line only once.
My recommendation to every sender, even small senders and new senders: consider yourselves a bulk sender. Smaller senders are monitored by mailbox providers, too. Start on the right foot.
It is common for IT teams not to implement DMARC because “everything is fine on their end.” But they are not always aware of every SaaS platform the marketing team uses, every SMTP server run by third parties on your organization’s behalf, or every email server developers have configured in various dev and testing environments.
The core value of DMARC reporting is the complete picture it provides of your email traffic, exposing every sending infrastructure (discoverability) – internal or external, legit or spoofed.
Carefully reviewing DMARC reports lets you continuously monitor authentication and alignment health across every sending infrastructure and surface failures as they occur. This is critical because even small changes in DNS or in sending infrastructure can occur at any time. Even one accidentally deleted character or a DNS record that was not updated properly is enough to break domain authentication.
Without DMARC’s reporting mechanism, problems like these can go unnoticed and significantly damage your deliverability, causing harm that takes time to detect and repair. In many cases, by the time the problem is discovered, you are deep in the mud, and the fix is far harder.
The new standard highlights DMARC’s importance. Auditors and regulators can now point to an official standard, and the pressure on organizations to fall in line is expected to grow.
How to Set Up DMARC?
A TXT record configured in the domain’s DNS under the “_dmarc” subdomain.
An example DMARC record in the new standard’s format:
v=DMARC1; p=none; sp=quarantine; np=reject; rua=mailto:rua-email@domain.com
| ag | Value | Explanation |
|---|---|---|
| v | DMARC1 | DMARC version. Fixed value DMARC1. Unchanged in the new standard |
| p | none / quarantine / reject | The policy telling the receiving server what to do when SPF/DKIM authentication and alignment fail: none = the receiving server decides. quarantine = move to quarantine or spam. reject = reject the email |
| sp | none / quarantine / reject | Policy for existing sub-domains. If not set, the p policy applies (same as the organizational domain) |
| np | none / quarantine / reject | New in the standard: policy for non-existent sub-domains (returning NXDOMAIN). If not set, the sp policy applies, and in its absence, p |
| t | y / n | New in the standard: Testing mode. t=y signals that the policy is under test, and the expectation is that the receiving side will apply one level below what is declared ("reject" will be treated as "quarantine", and "quarantine" as "none"). There is no effect on a "none" policy, and no effect on report sending. The default is t=n - enforcement. |
| psd | y / n / u | New in the standard: intended for Public Suffix Domain operators only. Helps the Tree Walk identify the organizational boundary. Most senders should not touch this tag |
| rua | mailto:address | The email address to which Aggregate Reports are sent. Note: the option to specify a report size limit was removed in the new standard |
| ruf | mailto:address | The email address to which Failure Reports are sent. Recommended not to configure Failure Report reception |
| fo | 0 / 1 / d / s | Relevant to Failure Reports: 0 = report when both SPF and DKIM fail. 1 = report when SPF or DKIM fails. d = DKIM failure only. s = SPF failure only |
| adkim | r / s | DKIM alignment mode against the From domain. Default r (relaxed), s (strict) available |
The DMARC mechanism evaluates alignment between the MAIL FROM domain (also called the return-path, envelope-sender, or bounce address) and the RFC5322 From Domain (the address visible to recipients), and checks that alignment for SPF and DKIM.
Note: unlike old examples still circulating on the web the pct, rf, and ri tags are no longer part of the standard. A server conforming to the new standard ignores them.
If these tags are still present in your DMARC record, your email will not break – servers simply ignore them. But I encourage you to clean up the record and bring it into line with the current standard soon.
| Tag | What it did | Why it was removed and what to do instead |
|---|---|---|
| pct | Gradual enforcement by percentage | In practice, almost never implemented accurately by mailbox providers. A server conforming to the new standard treats any value as if it were 100. Instead: use the t tag (all or nothing) and manage the gradual rollout operationally |
| rf | Failure Report format | Only one supported format ever existed (AFRF), making the tag redundant. Can simply be removed |
| ri | Interval between Aggregate Reports | In practice, everyone received a daily report regardless of the value. Reports continue to arrive daily or more frequently. Can simply be removed |
Replace the Aggregate Reports address in the example with the address from your DMARC monitoring tool, or add another address if you want to report to more than one tool.
The record’s syntax matters. The v=DMARC1 tag must appear first, with the value DMARC1 in uppercase. The p tag follows, separated by a semicolon.
Meaning of the example record above:
Policy for the Organizational Domain (p) = none
Policy for existing subdomains (sp) = quarantine
Policy for non-existent subdomains (np) = reject
The record in the example above, is configured to receive only Aggregate Reports.
A correct and responsible policy evolution always starts at p=none to begin receiving reports. Later, after several months of actively monitoring and fixing the issues the reports surface, you can move to p=quarantine and then to p=reject.
Tip: under the new standard, you can already instruct receivers, at the initial monitoring stage (p=none, reports only, no enforcement), how to handle non-existent (unused) subdomains – improving your anti-spoofing posture from day one without risking anything.
By adding np=reject, a subdomain that does not exist in your DNS (and therefore should not send email) can be blocked right now, even while the Organizational Domain is still in monitoring mode.
The DMARC Journey: Moving to Enforcement Under the New Standard
Even after reaching p=reject (protecting the domain), the work is not done. You must keep monitoring reports and enable alerts, if your DMARC management platform supports them – by email, webhook to an automation system or a SIEM (Security Information and Event Management), SMS to an admin, or any other channel – so you know the moment something breaks in DNS or in the authentication of one of your sending servers or platforms.
Under the old standard, the pct tag promised (on paper) a gradual transition: enforce on 25% of traffic, then 50%, and so on. In practice it worked inconsistently. Different mailbox providers treated the tag differently, applied it to whatever share of traffic they chose, at their own discretion.
The new standard removed the pct tag and replaced the mechanism with the binary t tag: either the record is in enforcement, not in a testing mode (t=n), or when in t=y, it signals the receiving side that the policy is under test, and the expectation is that the receiving side will apply one level below what is declared (“reject” will be treated as “quarantine”, and “quarantine” as “none”. There is no effect on a “none” policy),. there is no effect on report sending. The default is t=n – enforcement.
The practical meaning of the DMARC journey toward the destination – enforcement:
- Choose a DMARC management and monitoring tool (See below – tips on choosing the right tool for you).
- Configure the DMARC record in your domain’s DNS according to the instructions you received.
- Start at p=none with full monitoring through a dedicated DMARC monitoring tool.
- Receive reports that expose all your sending infrastructures.
- Fix one sending source after another, until the reports show all legitimate traffic is authenticated and aligned (Note: Some email platforms do not allow alignment on SPF. See each platform’s documentation).
- If you operate multiple sending domains – move the low-risk domains to enforcement first (quick win).
- Even when everything looks clean, run at none for at least a month. It is quite common to discover that once a month, a test server nobody remembers exists wakes up and sends from an unauthenticated source. Run each stage for a meaningful period before moving to the next.
- Move to quarantine, keep monitoring for at least a month, and only then move to reject.
- Keep monitoring and tracking alerts.
This is exactly the process I have always recommended. The new standard has made it the only recommended path.
What changed in reporting under the new standard (RFC 9990):
- The XML schema gained new optional fields, including discovery_method (indicating whether the receiver used the legacy PSL or the new Tree Walk), a testing-mode indication, an np field, and a generator field identifying the software that produced the report.
- Requirements that were “recommended” (SHOULD) became “mandatory” (MUST): the attachment’s media types (application/gzip or text/xml), the report file name format, and the email subject format.
- Verification of external report destinations (when rua points to a different domain) became mandatory for report generators.
If you use a DMARC monitoring platform, make sure its external destination verification record is in place (see below).
Sending DMARC reports to a free email account under Gmail, for example, is not possible. - The report size limit option in the rua tag was removed.
Existing monitoring tools keep working. Tools updated for the new standard will extract richer information from the new fields.
Aggregate Reports let you discover sending infrastructures – yours and those of third parties you have authorized to send on behalf of your domain – and fix broken authentication settings on those servers.
DMARC reports will also surface sending systems that may be impersonating your domains. That is, after all, DMARC’s original purpose: protecting your domain from abuse and impersonation.
Failure Reports – DMARC Failure Reports
What used to be called “forensic reports” is now officially called Failure Reports, with a dedicated RFC (RFC 9991) and a stronger emphasis on privacy risks and personally identifiable information (PII).
In most scenarios, there is not need to configure “Failure Reports” reception. They contain personal data such as email addresses. The Aggregate Reports are sufficient, and most servers do not send Failure Reports anyway – precisely because of GDPR and equivalent privacy laws. The new standard only reinforced these reservations.
If you nevertheless want Failure Reports, configure the record accordingly using the ruf tag.
How to Choose the Right DMARC Monitoring Tool?
At first glance, the DMARC tooling market makes no sense: there are free tools, there are tools at $4 per domain per month with unlimited volume and a year of history, and there are tools starting at several hundred dollars per month per domain. They all receive exactly the same XML reports. So what explains the gaps?
The difference is not the data. It is what the tool does with it: how digestible the analysis is, how much work remains on your side, the level of protection the alerting provides, and the integrations with other systems.
Free tools fit an initial assessment and a single domain with low traffic. The limits arrive quickly: short history, no alerts or only basic ones, no team members (important in an organizational setting), and sometimes incomplete report processing. If all you want is to know “who is sending on behalf of my domain” – it is a far better starting point than publishing no DMARC record at all, or publishing a useless one.
Inexpensive tools (single-digit dollars per domain per month) now cover what most businesses actually need: full Aggregate Report processing, sending source identification, change alerts, and sufficient history. A business with one or two domains, a known sending stack (an ESP, a CRM, Google Workspace or Microsoft 365), and one person reading the reports will probably get no real added value from an expensive tool.
Expensive tools are not selling reports; they are selling the management of a project: human guidance through the journey to p=reject, management of dozens or hundreds of domains under one organization, team permissions, SIEM integrations, hosted SPF, DKIM, and DMARC management within the tool itself, SLA-backed support, and reporting for executives and auditors. An organization with dozens of domains, multiple IT teams, and regulatory exposure is paying to reduce operational load, not for report parsing.
So How Do You Decide? Four Questions:
- How many domains and sending sources do you have? One domain with three sources – an inexpensive tool is enough. Dozens of domains with rotating third parties (agencies, sending sources) – you will benefit from what a more sophisticated tool offers.
- Who is going to read the reports? If the answer is “nobody,” the most expensive tool in the world will not help. If there is a team, evaluate permissions, alerts, and integrations. I have a client paying about $3,000 a year for a DMARC monitoring tool, and nobody on their team has touched it in six months…
- Where are you in the journey? At the p=none discovery stage, a simple, inexpensive tool delivers most of the value. Moving a complex environment to enforcement – guidance and advanced features justify themselves. Remember that DMARC is a journey: do not get stuck at none, and on the other hand, even at reject the work is not done and monitoring must continue.
- What happens when something breaks? Check before you pay: how quickly will you get an alert about a new failing source? That is, in the end, the reason you are monitoring.
And one update specific to the new standard: before committing to a tool, verify that it already supports the updated report schema (RFC 9990) and the new tags, and that its external destination verification record is configured as required – under the new standard, without it, reports simply will not arrive.
The standard was only just published. As with ESPs and other SaaS tools, some vendors update slowly (or not at all). Price is a consideration; a tool that has not been updated to meet the new DMARC standard is a candidate for disqualification.
Common Mistakes in DMARC Implementation
Not using a DMARC monitoring tool
Your DMARC record might look perfectly fine, but in reality, if you’re not using a DMARC monitoring tool (see below for tips on how to choose the right one for you), you don’t know what’s going on in your “email network”.
DMARC reports are in XML format, almost unreadable to the human eye without a DMARC monitoring/parsing tool.
Without a DMARC monitoring tool, it’s like seeing a single frame from an entire movie, without the ability to drill down and really understand what’s happening in your email network.
Starting at p=none and staying there…
A common mistake among those who already implemented DMARC is misunderstanding the mechanism. DMARC is not fire-and-forget but a mechanism you work with continuously: receiving reports and alerts, reviewing them regularly, and fixing what they surface.
The goal is to move from p=none (which provides zero domain protection) to p=quarantine and finally to p=reject. The “DMARC journey” usually takes several months of work. Even at the highest enforcement level – reject – monitoring and alert review must continue.
The neutral p=none stage is an important step that enables report collection without affecting your mail flow. Starting directly at quarantine or reject effectively tells the receiving side to block or reject mail from unauthenticated sources. The none stage lets senders understand the full picture and improve accordingly, without yet instructing receivers on what to do in the event of misalignment or authentication failure.
Under the new standard, you can block non-existent subdomains with np=reject already at this initial stage.
Implementing an incorrect or worthless DMARC record
Typos in DMARC records are common, as are implementations that are wrong or entirely useless – for example, DMARC with no report reception:
v=DMARC1; p=none;
In many cases, this is the exact record your ESP suggests. Do not make that mistake. Configure a proper DMARC record through a DMARC monitoring tool.
Implementing DMARC on a subdomain only, not on the Organizational Domain
Another common finding: DMARC implemented only on a subdomain and not on the Organizational Domain. DMARC’s purpose is usually to protect the Organizational Domain and every subdomain beneath it. Separate records for subdomains are possible, but most senders do not need them. With the move to the DNS Tree Walk, it is doubly important to know which record will be discovered first for each sending source.
Leaving deprecated tags in place
A new mistake born with the new standard: records containing pct, rf, or ri. They will not break anything, but they signal an unmaintained record, and in the case of pct they can create a gap between what you think is happening (partial enforcement) and what actually happens (full enforcement at servers conforming to the new standard). Clean the record up and bring it in line with the current standard.
Not implementing DMARC on all of the business’s domains
Every business should implement DMARC properly on all its domains, not only on sending domains. On non-sending (parked) domains, configure an SPF record that fails everything and a DMARC policy in enforcement mode.
A significant phishing attack recently allowed a sophisticated attacker to send email from the domain of Israel’s Ministry of Justice. The attack succeeded, among other reasons, because the domain was not at enforcement – which could have prevented it.
For DMARC policy deployment and monitoring, I recommend using an external tool (see the list here) rather than the configuration your ESP suggests.
Example SPF record for parked domains:
parked-domain.co.il TXT v=spf1 -all
Not granting external authorization
The DMARC protocol is designed to send reports to the monitored domain. When using an external monitoring tool, you must authorize report delivery to the external domain. Under the new standard, this verification went from recommended to mandatory for report generators – so without the authorization record on the external domain receiving your reports, reports simply will not arrive.
This is the TXT record configured in the monitoring tool’s DNS (the tools handle this for you):
domain.co.il._report._dmarc.external-dmarc-tool-domain.com
Not continuing DMARC monitoring
DMARC monitoring through a dedicated tool gives businesses ongoing reporting over time. In many tools, retention – how long report history is kept – is part of the pricing. The mistake is that after implementation, no continuous monitoring and improvement process takes place. The work does not end at deployment. Ongoing reports let you track every change in your sending infrastructure, and in infrastructures attempting to impersonate your domains.
See more DMARC implementation mistakes here
Frequently Asked Questions
DMARC
What is DMARC?
DMARC is a protocol for protecting domains against impersonation and for monitoring email authentication. It does not authenticate the domain itself (SPF and DKIM do that) – it rides on top of them, letting the Domain Owner publish a policy telling Mail Receivers what to do with messages that fail (deliver, mark as spam, or reject), and where to send DMARC reports.
Is there a standard called DMARC 2 or DMARC 2.0?
In May 2026, an updated DMARC standard was published, nicknamed DMARC 2.0 or DMARCbis while in development. Today you can simply call it: DMARC. The version identifier in the DNS record did not change – records still begin with v=DMARC1, and existing records keep working. The standard does include several changes and tags that are no longer valid.
What are the RFC documents of the new DMARC standard?
The new standard consists of three documents published in May 2026: RFC 9989 (the protocol), RFC 9990 (Aggregate Reporting), and RFC 9991 (Failure Reporting). Together they replace RFC 7489 from 2015 and RFC 9091.
What is the essential difference between the old and new standards?
- The move from Informational status to Proposed Standard on the IETF’s official Standards Track.
- Replacement of the Public Suffix List with the DNS Tree Walk algorithm.
- Removal of three tags (pct, rf, ri).
- Addition of three new tags (np, t, psd).
- Explicit normative guidance to Mail Receivers on enforcing reject policies.
Will my existing DMARC record stop working?
No. Backward compatibility is complete. Mail Receivers continue to read existing records; deprecated tags are simply ignored. There is no need to rush a change, but you should know the differences and remove obsolete tags at your next DNS update. One reason to act sooner is the new np tag – worth adding at reject to protect non-existent subdomains.
What is the DNS Tree Walk?
The DNS Tree Walk is the algorithm by which a Mail Receiver discovers the applicable DMARC policy and the Organizational Domain under the new standard. Instead of relying on the external Public Suffix List, the receiver queries the DNS directly: it looks for a record at the sending domain (often a subdomain), and if none exists, climbs the hierarchy, up to eight levels. The first record found is authoritative.
Which DMARC tags were removed in the new standard?
Three tags: pct (percentage-based enforcement, never implemented consistently), rf (Failure Report format, redundant since only one format existed), and ri (report interval, effectively ignored). Receivers ignore these tags in existing records. Remove them.
What does the new np tag do?
The np tag defines a separate policy for non-existent subdomains. It protects subdomains that do not exist in your DNS. A non-existent subdomain sends no mail anyway, so set np=reject today – even while the Organizational Domain is still at p=none – with zero risk to mail sent from your Organizational Domain or from existing subdomains (which you can govern with the sp tag).
What replaces the pct tag in the new standard?
The new standard has no pct tag. It is replaced by the new binary t tag: t=y marks testing mode, in which the receiver is asked not to apply the policy (equivalent to the old pct=0), and t=n (the default) marks full enforcement. There are no intermediate percentages – the gradual path to enforcement is managed operationally, using Aggregate Reports through a DMARC monitoring tool.
Why does forwarding break domain authentication and fail DMARC?
Relaying messages to other addresses almost always breaks SPF, because SPF is evaluated against the IP address of the last transmitting server – and the intermediary’s IP is not in the origin domain’s SPF record. DKIM usually survives, unless the message was modified (a footer added, for example). For instance: you configured a rule forwarding messages from your mobile carrier containing the word “invoice” to your bookkeeper. That can be exactly why the message never arrives, or lands in quarantine, per the policy published by the sending domain (the carrier, in this case). The new standard also clarifies that SPF is evaluated strictly against the MAIL FROM identity, with no HELO fallback.
Does the new standard incorporate ARC as the solution to the forwarding problem?
No. ARC (RFC 8617) remains a separate document with Experimental status and is not part of the new DMARC standard’s mechanism. The standard addresses the problem differently: it instructs Mail Receivers not to reject a message solely because a reject policy was published, requiring them to apply additional judgment. A receiver may use ARC as one input to that judgment, but that is its local decision, outside the standard.
What happens when the receiving server does not enforce the DMARC policy I published?
That is legitimate, documented behavior. The new standard explicitly states that a Mail Receiver may accept a message that failed DMARC even under a reject policy, and recommends not rejecting solely on the basis of the policy. In monitoring tools that support the new standard, the deviation is documented in the Aggregate Report’s reason element, so you can see exactly when and why your policy was not applied as written.
What changed in DMARC reporting under the new standard?
- RFC 9990 added new fields to the XML schema (including discovery_method, a testing-mode indication, and a generator field).
- Format requirements went from “recommended” to “mandatory.”
- The size limit in the rua tag was removed.
- External report destination verification (when reports go to an address outside the monitored domain) became mandatory. Without the external authorization record, reports to an external monitoring tool simply will not be sent.
What should you do now, following the new DMARC standard?
- Remove the pct, rf, and ri tags from your record if present.
- Add np=reject to block non-existent subdomains.
- Verify that your DMARC monitoring tool supports the new report schema and that its external authorization record is in place.
Email Deliverability Consultant | Blogger & Podcaster. Helping global email senders, startups, email and digital agencies, and ESPs with email deliverability, email authentication, and strategy.
