Red Sift’s definitive guide to email security
What are the global mandates and guidance for DMARC in 2026?
For cybersecurity, email security and IT teams, understanding and adhering to global DMARC (Domain-based Message Authentication, Reporting, and Conformance) requirements is imperative.
At Red Sift, we have put together a tabulated overview of DMARC mandates and guidance enforced across different regions worldwide. Our aim is to provide a clear, unambiguous guide that consolidates the varying global requirements into one accessible format.
Whether you are an IT security professional, email administrator, or a compliance officer, this table will serve as an essential tool to ensure your organization’s email security aligns with international best practices and requirements.
Global DMARC mandates and guidance
Affected Geo | Name | Description | Mandate type | Learn more |
Global | New requirements for bulk senders | Those sending over 5,000 emails a day must authenticate email-sending domains with TLS, DKIM, SPF, DKIM, or SPF alignment and have a DMARC policy of p=none. | Private sector mandate | |
Global | PCI DDS v4.0 Req 5.4.1 | “Automated mechanisms” must be deployed to detect and protect against phishing attacks. Though this requirement is for “processes and mechanisms” and does not point to a specific solution, best practices would point to implementing DMARC, SPF, and DKIM. | Compliance mandate | |
Canada | Email Management Services Configuration Requirements | Ensure that the sender or recipient of government email can be verified using inbound mail using the Sender Policy Framework; Domain Keys Identified Mail (DKIM); and Domain-based Message Authentication, Reporting and Conformance (DMARC). | Mandate for government agencies | |
Denmark | Minimum technical requirements for government authorities 2023 | All governmental agencies are required to implement a DMARC policy of p=reject on all domains. | Mandate for government agencies | |
New Zealand | 2022 New Zealand Information Security Manual, v3.6, section 15.2 | The future replacement for SEEMail will use DMARC and therefore vendors and agencies will need to be compliant. 1. Change of DMARC control compliance from SHOULD to MUST [CID:6019] [CID:6021] 2. Change of DMARC policy setting from p=”none” to p=”reject” [CID:6020] 3. Change of DKIM control compliance from SHOULD to MUST [CID:1797] [CID:1798] | Mandate for government agencies | |
Ireland | Public Sector Cyber Security Baseline Standards, section 2.9 | Public service bodies must implement TLS, SPF, DKIM, and enforce DMARC on all inbound mail. | Mandate for government agencies | |
Netherlands | “Comply or Explain” standards | Mandatory guidelines for government agencies require DKIM, SPF, and DMARC as well as STARTTLS and DANE. | Mandate for government agencies | |
Saudi Arabia | Guide to Essential Cybersecurity Controls (ECC) Implementation, section 2-4-3 | National organizations must implement all necessary measuresto analyze and filter email messages (specifically phishing emails and spam) using advanced and up-to-date email protection techniques. Recommended approachesinclude DKIM, SPF, and DMARC. | Mandate for government agencies | |
UK | Government Cybersecurity Policy Handbook Principle: B3 Data Security | Government departments shall have DMARC, DKIM, and SPF records in place for their domains. This shall be accompanied by the use of MTA-STS and TLS Reporting. This requirement originated from the 2018 Minimum Cybersecurity Standard. | Mandate for government agencies | |
UK | Securing government email | All emails that public sector organizations run on the internet must encrypt and authenticate email by supporting TLS and DMARC at minimum. | Mandate for government agencies | |
UK | Updating our security guidelines for digital services | Any service that runs on service.gov.uk must have a published DMARC policy. | Mandate for government agencies | |
United States | Binding Operational Directive 18-01: Enhance Email and Web Security | Requires all federal agencies to bolster web security with STARTTLS, SPF, DKIM, and DMARC with a policy of p=reject. | Mandate for government agencies | |
Australia | Cybersecurity guidelines: Guidelines for Email | Recommends implementing SPF, DKIM, and DMARC with a policy of p=reject | Guidance | |
Australia | How to combat fake emails | Suggests using SPF, DKIM, and DMARC to prevent domains from being used as the source of fake emails. | Guidance | |
Australia | Malicious email mitigation strategies | Recommends the most effective methods of protecting organizations from email-borne attacks, and includes deploying DKIM, SPF, and DMARC with a “p=reject” policy. | Guidance | |
Canada | Implementation guidance: email domain protection (ITSP.40.065 v1.1) | For complete protection against spoofing, organizations should implement SPF, DKIM, and DMARC. | Guidance | |
EU | Email communication security standards | Recommends using STARTTLS, SPF, DKIM, DMARC, and DANE to protect email communications. | Guidance | |
Germany | Measures to defend against spam and phishing, Section 3.1 | Proposed measures to internet service providers that can be used to reduce the malware and spam problem SPF, DKIM and DMARC. | Guidance | |
Saudi Arabia | Phishing Campaigns for Emotet Malware | Implement Domain-Based Message Authentication, Reporting & Conformance (DMARC) to detect email spoofing using Domain Name System (DNS) records and digital signatures. | Guidance | |
Scotland | A Cyber Resilience Strategy for Scotland: Public Sector Action Plan 2017-2018, v2 | Public bodies should take advantage of DMARC anti-spoofing. | Guidance | |
UK | Email security and anti-spoofing v2 | Make it difficult for fake emails to be sent from your organization’s domains using SPF, DKIM, and DMARC with a policy of at least p=none, including parked domains. Protect your email in transit with TLS. | Guidance | |
UK | Phishing attacks: defending your organisation v1.1 | DMARC, SPF, and DKIM are Layer 1 defenses for stopping spoofed emails used to attack an organization. | Guidance | |
United States | CIS Critical Security Controls v8.0, IG2-9.5 | Implement DMARC policy and verification, starting with Sender Policy Framework (SPF) and the DomainKeys Identified Mail (DKIM) standards. | Guidance | |
United States | CISA INSIGHTS Enhance Email &Web Security | Enable DKIM, SPF, and DMARC with a policy of p=reject. | Guidance | |
United States | Multi-State Information Sharing and Analysis Center (MS-ISAC) Ransomware Guide | To lower the chance of spoofed or modified emails from valid domains, implement DMARC policy and verification. | Guidance | |
United States | NIST 800-53 Security Controls Catalog Revision 5: SI-08 | Employ spam protection mechanisms at system entry and exit points to detect and act on unsolicited messages. DMARC, SPF, and DKIM are one way to address this. | Guidance | |
United States | NIST Special Publication 800-177Revision 1: Trustworthy email | Recommends implementing SPF, DKIM, and DMARC, among other controls to enhance trust in email. | Guidance |
Where to go from here?
The landscape of email security and authentication is constantly evolving.
At Red Sift, we understand the complexities involved in implementing and managing DMARC. Our award-winning Red Sift OnDMARC is designed to simplify the path to DMARC enforcement, offering you best-in-class technology and expertise.
Frequently asked questions: Email security guide
All email security measures (apart from DMARC) are ineffective at spotting a malicious email when it appears to come from a legitimate domain. This is because of a flaw in Simple Mail Transfer Protocol (SMTP). In October 2008, the Network Working Group officially labelled it 'inherently insecure', stating that anyone could impersonate a domain and use it to send fraudulent emails pretending to be the domain owner.
Anyone with a very basic knowledge of coding can learn the steps required to impersonate someone's email identity through a quick Google search. The result is an email that looks legitimate without typical phishing indicators. With 3.4 billion phishing emails sent every day, email systems remain the prime target for cybercriminals.
SPF (Sender Policy Framework) verifies that an email is sent from an IP address authorised by the sending domain's SPF record through a DNS TXT record listing authorised mail servers.
DKIM (DomainKeys Identified Mail) uses a cryptographic signature, validated via a public key in DNS, to confirm that the email's content hasn't been altered and comes from an authorised domain. Both are essential to email security, but neither prevents exact impersonation.
While the protocols tell the recipient who the email is from, the recipient has no instruction to act on this knowledge. Major inbox providers now require SPF and DKIM for bulk email senders in 2026.
DMARC stands for Domain-based Message Authentication, Reporting, and Conformance. It's an outbound email security protocol that allows domain owners to tell receiving inboxes to reject spoof emails. DMARC works by combining the results of SPF and DKIM to determine if your email is authentic and authorised.
The DMARC policy (defined by the "p=" tag in your DNS record) then tells recipient servers what to do with it. DMARC stops exact domain impersonation by instructing recipient servers not to accept any emails which aren't authenticated. In 2026, DMARC has become a standard requirement for organisations sending bulk email.
The SPF specification limits DNS lookups to 10. If your SPF record exceeds this, SPF will fail. The SPF mechanisms counted are: a, ptr, mx, include, redirect and exists. In reality, 10 lookups aren't enough because most businesses use multiple email-sending tools.
G Suite alone takes up 4 DNS lookups, add in HubSpot for marketing which uses 7 lookups and you're already over the limit. As soon as you go over 10 SPF lookups, your email traffic will begin to randomly fail validation. This is why organisations in 2026 are shifting to dynamic SPF management rather than trying to manually maintain flattened records.
Mail Transfer Agent Strict Transport Security (MTA-STS) is a standard that enables the encryption of messages being sent between two mail servers. It specifies that emails can only be sent over a Transport Layer Security (TLS) encrypted connection which prevents interception by cybercriminals. SMTP alone does not provide security, making it vulnerable to man-in-the-middle attacks where communication is intercepted and possibly changed.
Additionally, encryption is optional in SMTP, meaning emails can be sent in plaintext. Without MTA-STS, an attacker can intercept the communication and force the message to be sent in plain text. In 2026, MTA-STS has become a standard security control for organisations handling sensitive communications.
By implementing DMARC you benefit from stopping phishing attempts that appear to come from you, stronger customer trust, reduced cyber risk and compliance with bulk sender requirements from Google, Yahoo and Microsoft.
DMARC strengthens compliance with PCI DSS 4.0 and enhances overall organisational resilience against evolving cyber threats. Once at p=reject (enforcement), DMARC blocks vendor fraud, account takeovers, and email spoofing by stopping bad actors from using your domain to send phishing emails and carry out Business Email Compromise (BEC). According to Verizon's 2025 Data Breach Investigations Report, BEC attacks constitute more than 17-22% of all Social Engineering incidents.
Red Sift OnDMARC accelerates the DMARC journey with automated sender discovery, prescriptive fixes, anomaly detection, and role-based access for global teams. By 2026, leading platforms enable enterprises to reach p=reject enforcement in 6-8 weeks rather than the six month timelines once typical.
One of the most commonly reported benefits of OnDMARC is an average time of 6-8 weeks to reach full enforcement. The platform's powerful automation continuously analyses what's going on across your domain, surfacing alerts for where and how to make necessary changes. Within 24 hours of adding your unique DMARC record to DNS, OnDMARC begins to analyse and display DMARC reports in clear dashboards.
Major email providers including Microsoft, Google, and Yahoo now mandate DMARC for bulk senders (organisations sending 5,000+ emails per day) as of 2024-2025, and these requirements have become standard in 2026.
Beyond inbox provider requirements, certain industries and government regulations are moving toward mandating DMARC. U.S. federal agencies are required to use DMARC, as are DORA regulated payment processors. Additionally, DMARC implementation strengthens compliance with regulations including PCI DSS 4.0, GDPR, and NIS2. For cybersecurity, email security and IT teams, ensuring your organisation's email security aligns with international best practices and requirements is essential.