Email is a vital tool for the lifeblood of business communication all around the world. It’s so critical to the everyday running of organizations big and small, that many would agree it’s just as essential a service as electricity or water.

But its importance is exactly what makes email vulnerable from a cybersecurity perspective. With 3.4 billion phishing emails sent every day, it's evident that email systems are the prime target for cybercriminals seeking access to your business. All it takes is a single employee  to fall victim to a socially engineered scam, click on an infected link, or download a malicious attachment, and your entire operation could grind to a halt.

Given how important it is for organizations to secure their email, we’ve developed this comprehensive guide to help both beginners and buyers with their email security related queries. In the following chapters, you’ll find in-depth information on:

The email landscape and the types of threats that exist 

The different types of email security protocols or how they protect organizations from attacks, such as SPF, DKIM, MTA-STS, and DMARC

What to look for in an email security provider

If you're an email security architect or an analyst looking for a more technical guide, visit our Technical Email Configuration Guide. This comprehensive handbook explores SPF, DKIM, DMARC, MTA-STS, and more, offering insights and practical tips for enhancing your email security posture. 

Red Sift's guide helps beginners and buyers with information on the email landscape, threat types, and how to stay protected.

Introduction to Red Sift's Email Security Guide

Introduction

The problem with email: It isn’t as secure as you thought

Email security technologies come in many forms. But ultimately, all have a common set of goals: keeping the volume of spam emails down, detecting threats, and stopping them from reaching your inbox.  

More often than not, these technologies work by looking for the most common traits of a malicious email - like a blacklisted IP address or a suspicious domain - and then blocking it from reaching your inbox.  Exact domain impersonation is when an attacker uses your domain to send a fraudulent email.

All email security measures (apart from DMARC - more on that later!) 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) - the internet standard for transmission of electronic messaging. In October 2008, the Network Working Group officially labeled it ‘inherently insecure’. They said 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. All it takes is a quick Google search. The result is an email that looks legitimate and doesn’t have the typical indicators of a phishing attack, such as a suspicious email address. A recipient email server will then allow this email into an individual’s inbox (if the right security measures are not in place). It’s then hard for them to see that the email is, in fact, a phishing attack using a spoofed domain. 

A spoofed domain is a deceptive website or email address created to resemble a legitimate domain. There are various types of spoofing techniques, such as:

Exact domain impersonation - when an attacker spoofs your exact domain only. For example, yourcompany.com

Lookalike domain - when an attacker registers a domain that is so similar to the original domain, it makes it difficult to spot. This is also referred to as typosquatting. For example,  yourc0mpany.com

Subdomain spoofing - when an attacker creates a legitimate-looking subdomain page where they might set up a malicious form that harvests credentials. For example, login.yourcompany.com 

Email phishing is when an attacker or ‘bad actor’ sends fraudulent emails pretending to be from a reputable organization, with the purpose of getting the recipient to reveal sensitive information like bank details or personal data. Sometimes, phishing emails are sent with the intention of deploying malicious software to the victim’s infrastructure. 

According to APWG’s Q4 2023 Phishing Activity Trends Report, 2023 was a record year for phishing attacks. In total, there were almost five million phishing attacks in 2023, the worst year for phishing on record and eclipsing the 4.7 million attacks seen in 2022.

A traditional phishing attack usually involves one fraudulent email being sent to multiple recipients. However, phishing attacks are becoming increasingly personalized thanks to the rise in social engineering, the practice of using psychological tactics to get victims to divulge sensitive information. There’s much more information readily available online, and attackers can use this to craft more specific and targeted attacks. 

While some phishing attacks focus on the consumer, bad actors know that there is much more to be gained by targeting an organization. Business Email Compromise (BEC) is an umbrella term that describes phishing attacks that target an organization by impersonating its domain. The attacker relies heavily on Social Engineering and crafts a phishing email designed to look like one from someone inside the business  (usually the CEO). The main aim of this type of attack is to steal money or sensitive data.

According to Verizon’s 2023 Data Breach Investigations Report, BEC attacks (a type of Social Engineering attack) remain remarkably efficient and lucrative for cybercriminals, as indicated by the nearly twofold increase in Verizon's incident 2023 dataset. Currently, BEC attacks constitute more than 50% of all Social Engineering incidents.

The types of attacks that come under the umbrella term Business Email Compromise include: 

Ransomware is malicious software that encrypts files or locks down computer systems, demanding payment (a ransom) for their release.

When the attacker poses as the CEO or another senior executive and targets employees. 

When the attacker tries to trick the recipient into paying an invoice or multiple invoices. 

An attack targeting those with access to Personally Identifiable Information (PII), such as HR managers.

Account compromise refers to unauthorized access to a user's account by a third party, often resulting in the theft of sensitive information or misuse of the account for malicious purposes.

Phishing attacks have varying levels of sophistication

It’s not surprising that many users are deceived by phishing emails. When done well, they can be almost impossible to spot. Organizations that experience phishing attacks haven’t necessarily done anything wrong, and the attacker doesn’t even need access to their systems to carry one out. But regardless, many governments and regulators consider organizations to have a responsibility to safeguard their customers against phishing attacks. So organizations that haven’t taken appropriate measures to safeguard their customers may be liable for a data breach - and penalties. 

In the last decade, a series of email protocols have been introduced by industry leaders to try and improve email security, but email impersonation bypasses many of these. 

Dive into the next chapter to gain a quick understanding of these protocols and what they protect against. 

In October 2008, email was officially labeled as ‘inherently insecure’. It was said that anyone could impersonate a domain and use it to send fraudulent emails pretending to be the domain owner. 

The problem with email: It isn’t as secure as you thought 

Sender Policy Framework (SPF) is an email authentication protocol designed to stop attackers from sending emails that appear to come from your domain. An SPF policy tells receiving mail servers which sending sources are legitimate for your domain, helping prevent email spoofing, phishing, and domain impersonation.

Your SPF policy is published in your Domain Name System (DNS) as a TXT record, listing the mail servers (IP addresses) authorized to send on your behalf. When an email is sent, the recipient’s mail server checks this policy to confirm whether the sending IP address is approved. If it matches, the message is delivered; if not, it may be flagged as spam or rejected.

An SPF lookup is when the DNS receiving your email has to ‘look up’ the IP addresses present in any of the include statements within your record, to check if they match with the IP sending your email. 

An SPF include is a feature within SPF records that allows domain owners to include the SPF records of other domains in their own SPF policy. This enables streamlined management and ensures that the included domains' email sending policies are considered when determining the legitimacy of emails sent from the including domain.

The SPF lookup limit is the number of times a recipient DNS can carry out a lookup for a domain with a maximum cap set at 10.

You can add unlimited singular IP addresses to your record without incurring additional DNS lookups, as they are directly visible in the record.

But this isn’t the case for include statements, and the number of IP addresses an include has equals the number of lookups the receiving DNS has to carry out. This contributes to your maximum total of 10. 

So for example, you might have 3 IP addresses listed in your SPF record as they are, an include statement for Google (which contains 4 IP addresses) and an include statement for Mimecast (which contains 6). The receiving DNS doesn’t need to carry out lookups for the visible IPs, but it does for the Google and Mimecast include statements. So in this case, you’ve reached your total of 10.

In reality, 10 lookups aren’t enough, because most businesses use a number of tools that send emails on their behalf. These will all have their own include statements, which will include IP addresses, and so will require lookups. If you go over the limit, then you’ll likely fail authentication and your deliverability will suffer.

One of the main reasons the SPF record might be failing for your email traffic is the “too many DNS lookups” error. The SPF specification limits the number of DNS lookups to 10. If your SPF record results in more than 10 DNS lookups then SPF will fail. The SPF mechanisms counted towards DNS lookups are: a, ptr, mx, include, redirect and exists. “ip4”, “ip6” and “all” do not count towards the lookup limit.

If that all sounds a bit too technical, think about it this way. G Suite alone takes up 4 DNS lookups, add in Hubspot for marketing which uses 7 lookups then you’ll already be over the 10 lookup limit! As soon as you go over 10 SPF lookups, your email traffic will begin to randomly fail validation.

What is DomainKeys Identified Mail (DKIM)?

DKIM stands for DomainKeys Identified Mail, which is an email authentication protocol designed to prevent message modification in transit, a method often used in phishing and email scams.

DKIM is a more recent standard and more complex than SPF. Its functionality is based on using asymmetric cryptography in the signature parts of the email. There is a private key stored on the server that sent the email, a place where it could never be read by the end-user, and a public key which is published in the DNS record of the sender’s domain and is used to decrypt email signatures.

In other words, when an email is composed, its headers and body are signed using the private key of the sender to create a digital signature, which is also sent as a header field along with the email. On the receiver’s side (if DKIM is enabled), the server retrieves the public key and verifies if the email was indeed signed by the sending domain. If the signature is successfully validated, that proves that the sending domain sent the message and also that the headers and body of the message have not been modified or tampered with during transmission.

A DKIM signature is a unique cryptographic value embedded in the header of an outgoing email. Generated using the sender’s private DKIM key, this signature allows the recipient’s mail server to retrieve the corresponding public key from DNS and confirm that the message was sent from an authorized source and that its content has not been altered in transit.

A DKIM key is the cryptographic key pair used in DKIM authentication. The private key is securely stored on the sending mail server and used to generate the DKIM signature for each outgoing email. The public key is published in the sending domain’s DNS as a TXT record, allowing receiving servers to verify the signature and confirm the email’s integrity and authenticity.

Get the in-depth scoop on all things DKIM in our technical configuration guide.

Yes. DKIM (DomainKeys Identified Mail) is a critical email authentication protocol that protects against spoofing, phishing, and message tampering. It adds a cryptographic signature to each outgoing message, enabling receiving servers to verify that the email’s content hasn’t been altered and that it comes from an authorized domain. DKIM is also a core component of the DMARC verification process, working alongside SPF to enforce domain alignment and strengthen email security.

What is the difference between SPF and DKIM?

SPF (Sender Policy Framework) verifies that an email is sent from an IP address authorized by the sending domain’s SPF record. 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 that it comes from an authorized domain. SPF focuses on sender authorization, while DKIM ensures message integrity and authenticity.

In this chapter, we discuss Sender Policy Framework (SPF) and DomainKeys Identified Mail (DKIM) and explain how they protect you from email-based threats.

Sender Policy Framework (SPF) and DomainKeys Identified Mail (DKIM)

SPF and DKIM

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 to sending servers that emails can only be sent over a Transport Layer Security (TLS) encrypted connection which prevents emails from being intercepted by cybercriminals.

The Simple Mail Transfer Protocol (SMTP) alone does not provide security, making it vulnerable to malicious attacks such as man-in-the-middle attacks. A man-in-the-middle attack is where communication between two servers is intercepted and possibly changed without detection by the recipient.

In addition, encryption is optional in SMTP, which means that emails can be sent in plaintext. If a plaintext email was intercepted in transit, it could easily be read and manipulated. Without MTA-STS, an attacker can intercept the communication and force the sending service to send the message in plain text. 

By enabling MTA-STS, a TLS connection is required which ensures encryption and keeps your emails private. The MTA-STS standard is so critical to improving the security of SMTP that it has widespread support among major mail service providers such as Google and Microsoft.

For more technical details, visit the MTA-STS and TLS chapter in our Technical Configuration Guide.

MTA-STS is a standard that ensures messages are encrypted during transfer between mail servers, protecting emails from interception by cybercriminals.

What is MTA-STS?

MTA-STS

DMARC stands for Domain-based Message Authentication, Reporting, and Conformance. It’s an outbound email security protocol that allows domain owners to take back control of their email identity by telling receiving inboxes to reject spoof emails. It works alongside SPF and DKIM to verify that an email is sent from an authorized source and that the visible “From” address aligns with the authenticated domain.

DMARC stops exact domain impersonation by telling recipient servers not to accept any emails which aren’t authenticated to have come from you. So, bad actors cannot use your domain to send phishing emails and carry out Business Email Compromise (BEC).

DMARC works using the existing security protocols SPF and DKIM. Your SPF record is a whitelist of IP addresses you’ve authorized to send emails using your domain. DKIM acts like a digital signature, letting the recipient know you are who you say you are. When you first configure DMARC, you’ll spend some time classifying which senders you’ve authorized to send emails using your domain, and which you haven’t.

Both SPF and DKIM are essential to your email security setup, 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, i.e. it doesn’t know what to do with your email. 

So, DMARC works by combining the results of SPF and DKIM to determine if your email is authentic and authorized. Then, the DMARC policy you have in place tells recipient servers what to do with it. 

A DMARC policy is the set of rules published in your DMARC DNS record — defined by the “p=” tag — that tells receiving mail servers how to handle messages that fail DMARC authentication.

Your DMARC policy is essentially the instruction you give to receiving servers, telling them what to do with emails that come from your domain. There are three policies to choose from:

p=none: this policy tells the recipient server to accept all emails from your domain, regardless of whether they pass authentication or not.

p=quarantine: this policy tells the recipient server to send any emails from your domain that fail authentication to spam.

p=reject: this policy tells the recipient server to reject any emails coming from your domain that fail authentication.

Why a DMARC "reporting" policy isn’t enough

Adopting DMARC is a phased process. Starting with "p=none" allows you to monitor email flows without disrupting legitimate communications. During this phase, analyze DMARC reports to configure SPF and DKIM records correctly for all legitimate email sources. Once confident in your email authentication setup, you can progress to enforcement policies like "p=quarantine" (which directs failing emails to the spam/junk folder) and eventually "p=reject" for full protection.

It's important to note that while "p=none" provides valuable monitoring data, it does not prevent malicious emails from being delivered. Therefore, remaining at "p=none" leaves your domain vulnerable to abuse. Achieving a "p=reject" policy is the ultimate goal for securing your domain, as it actively blocks unauthorized emails. However, this transition should be managed carefully to ensure all legitimate email sources are properly authenticated, minimizing the risk of disrupting valid communications and passing through the “p=quarantine” stage.

To fully secure your emails, "p=reject" provides stringent protection against ever-growing threats. Starting with “p=none” is an excellent start and a structured implementation plan from Red Sift, you can enhance your domain's email security posture.

What’s the difference between DMARC and SPF?

SPF (Sender Policy Framework) is an email authentication protocol that validates sending server IPs against a domain’s SPF policy. DMARC (Domain-based Message Authentication, Reporting, and Conformance) uses SPF and/or DKIM to enforce domain alignment, apply reject or quarantine rules, and provide reports for monitoring email spoofing and phishing.

What’s the difference between DMARC and DKIM?

DKIM (DomainKeys Identified Mail) adds a digital signature to outgoing messages, verified via a public key in DNS, to confirm content integrity and domain authorization. DMARC (Domain-based Message Authentication, Reporting, and Conformance) combines DKIM and SPF results to enforce alignment, block or quarantine unauthenticated emails, and deliver detailed reporting.

SPF vs DKIM vs DMARC: How they differ and connect

SPF, DKIM, and DMARC work together to protect email domains: SPF verifies authorized sending IPs, DKIM ensures message integrity with cryptographic signatures, and DMARC enforces alignment between authentication results and the visible “From” domain while providing policy control and reporting.

What are the business benefits of implementing DMARC?

Aside from providing a strong email security posture, DMARC can offer some real business benefits too. Below are some of the key advantages of implementing DMARC.

DMARC provides reports showing most, if not all, emails that come from your organization’s domain. This contrasts with traditional cybersecurity solutions which only pick up inbound phishing emails. Without DMARC, organizations are not getting a complete picture of the number and scale of attacks against them.  

Protect your reputation and shut down brand abuse

Phishing attacks that use exact impersonation can cause considerable reputational damage. Phishing scams attract negative press, with liability often attributed to the organization that has been impersonated. 

Paying fake invoices or completing wire transfers from emails impersonating a business’ CEO is common. 

Get your registered logo on your emails 

BIMI (Brand Indicators for Message Identification) is a standard that enables your registered logo to be visible in the avatar slot of any DMARC authenticated emails you send, by using Verified Mark Certificates. BIMI increases your brand impressions, and research has found it has a significant positive impact on consumer trust, interaction, and purchasing decisions. Being DMARC compliant means you’re eligible to take advantage of this brand-enhancing reward.  

When DMARC is set up correctly at a policy of p=reject, senders signal to ISPs that they are actively taking measures to authenticate their emails and improve their domain security. This builds trust with ISPs, reducing the likelihood of legitimate emails being mistakenly marked as spam or phishing attempts.

Organizations that fail to take the necessary precautions to prevent email spoofing are likely to be considered less trustworthy. Customers may not trust emails that supposedly come from these organizations and could be deterred from using email to communicate with them, which can impact on those organizations’ ability to communicate effectively with their customers. By implementing DMARC, you’re putting a robust measure that confirms your organization’s identity in place 

Shadow IT refers to legacy systems or technology set up by various departments in a business to plug a gap in existing infrastructure, and it’s not always easy to identify or remove. DMARC gives you the visibility necessary to identify and resolve any outlying software or systems, meaning nothing will accidentally be sent out by these legacy systems. Implementing DMARC uncovers all the email services sending emails from your domain, whether you officially know about them or not.

How DMARC supports compliance and regulation efforts

DMARC helps organizations comply with email security recommendations made by global government bodies such as NIST, NCSC, and the European Commission.

The EU's revised Directive on Security of Network and Information Systems (NIS2 Directive) has dramatically increased the regulatory pressure on organizations to take proactive action against phishing through a DMARC policy of "reject.”

The NIS2 Directive is an EU regulation that establishes a high common level of cybersecurity across the EU. For 'Essential and Important Entities,' compliance with this directive is mandatory.

Although the text of the NIS2 Directive does not explicitly mention DMARC or a "reject" policy, several of its requirements are related to the principles that DMARC upholds, and the absence of a DMARC policy of "reject" could be considered to weaken compliance with as many as five of direct NIS2 requirements or principles. 

Security by Design and by Default: The NIS2 Directive requires ‘providers of public electronic communications networks or of publicly available electronic communications services’ to implement security by design and by default. As a global and well-accepted internet standard for the prevention of email domain impersonation, a DMARC policy of “reject” forms an important part of a security by design and by default strategy. 

Risk Management Measures: The NIS2 Directive requires 'Essential and Important Entities' to take appropriate and proportionate technical and organizational measures to manage the risks posed to the security of network and information systems. A DMARC "reject" policy aligns with this requirement as it is a key measure to manage the risk of email phishing and spoofing attacks, which can lead to the risks outlined in this document.

Supply Chain Security: The NIS2 Directive requires entities to ensure the security of their network and information systems, including those of their supply chain. A DMARC "reject" policy can help by ensuring that only authorized third-party vendors can send emails on behalf of the entity, which can help prevent phishing attacks that originate from compromised vendors as well as protect the third-party vendors themselves from becoming victims of attacks that impersonate an organization.

Incident Reporting: Entities must report incidents having a significant impact on the continuity of essential services. While DMARC itself is not a reporting mechanism for security incidents, the detailed aggregate and forensics reports it generates can help organizations identify and respond to security incidents related to email spoofing.

Resilience: Entities are required to take measures to ensure the resilience of their systems and networks. A DMARC "reject" policy contributes to this by protecting the organization's email communication system, a critical part of its network, from being misused by unauthorized senders.

Comply with Microsoft, Google and Yahoo’s bulk sender requirements 

From February 2024, Microsoft, Google and Yahoo rolled out new requirements for bulk senders, ushering in a new era of email compliance, which includes DMARC implementation. Microsoft, Google and Yahoo now require bulk senders – those who send more than or around 5,000 emails daily – to meet a set of authentication measures to ensure secure email delivery to addresses ending in gmail.com or yahoo.com.

The requirements came into effect on February 1, 2024, and include: 

Set up a SPF and DKIM for each domain that sends mail 

Send with an aligned ‘From’ domain in either the SPF or DKIM domains 

Publish a DMARC policy for each domain that sends mail with a least a policy of “p=none”

Ensure that sending domains or IPs have FcrDNS set up

Use a TLS connect for transmitting emails 

Enable one-click unsubscribe for recipients of promotional mail

Keep spam rates under 0.10% as reported by Google Postmaster Tools


The Digital Operational Resilience Act (DORA) is a regulatory framework by the European Union aimed at ensuring the digital operational resilience of the financial sector. It seeks to establish a stringent, harmonized set of rules for digital operational resilience, including areas such as ICT risk management, incident reporting, digital operational resilience testing, and more. 

Even if an organization is not classified as a financial institution, DORA defines criticality thresholds for services provided to financial institutions. If an organization is a direct service provider to a financial institution and its services meet these thresholds, then the company is subject to DORA. Furthermore, it is likely that under DORA, these financial institutions push more stringent security controls onto their providers, including DMARC with a policy of “reject”.

While DORA does not go into specific technical detail, it does press three relevant aspects for DMARC at a policy of “reject”:

​​ICT Risk Management: One of DORA's key aspects is to ensure effective ICT risk management. Implementing a DMARC "reject" policy directly contributes to this goal by preventing phishing attacks, email spoofing, and other email-based threats. This enhances the security of the ICT ecosystem, aligning with DORA's objectives.

Third-Party Risk: DORA requires financial institutions to manage and mitigate risks from their third-party service providers, including communication service providers. Implementing a DMARC "reject" policy can help reduce the risk posed by email-based threats, thereby enhancing security posture and reducing third-party risk for its financial institution clients.

Operational Resilience: DORA places a strong emphasis on the operational resilience of financial services providers. A DMARC "reject" policy can help enhance operational resilience by ensuring the integrity and authenticity of email communications, reducing the risk of disruptive incidents caused by phishing or other email-based attacks.

The Payment Card Industry Data Security Standard (PCI DSS) is a globally recognized framework designed to ensure that all companies that accept, process, store, or transmit credit card information maintain a secure environment. Implementing DMARC is recognised as an essential part of meeting these requirements. By ensuring that emails sent from a domain are authenticated through SPF and DKIM protocols, and providing domain owners with visibility into unauthorized use of their domain, DMARC supports PCI DSS 4.0.1's goal of protecting cardholder data environments. It reduces the risk of phishing attempts that could lead to breaches, helping organizations establish trust and improve security postures.

PCI DSS 4.0.1 calls for organisations to adopt a proactive, risk-based approach to cybersecurity, and DMARC aligns seamlessly with this framework. By enabling domain owners to enforce a "reject" policy for unauthenticated emails, DMARC actively prevents malicious emails from reaching their targets, addressing key compliance requirements around risk mitigation. Reporting capabilities also provide valuable insights into email ecosystems, enabling organizations to identify vulnerabilities and ensure continuous improvement. As a critical layer in email security, DMARC not only strengthens compliance with PCI DSS 4.0 but also enhances overall organisational resilience against evolving cyber threats.

To prepare for PCI DSS 4.0.1 compliance by March 31, 2025, organizations should start by conducting a gap analysis to identify areas that need improvement. Prioritizing the implementation of automated certificate management tools can help manage the complexities of certificate validation and renewal, such as Red Sift Certificates. Additionally, businesses should engage with Qualified Security Assessors (QSAs) to ensure their compliance strategies are sound and effective.

General Data Protection Regulation (GDPR) came into force in May 2018, requiring you to have Data Processing Agreements (DPAs) with every cloud service provider that handles EU consumer data on your behalf. With DMARC, if a cloud service provider does send emails using your company’s domain name in the ‘From’ field, then DMARC will reveal them to you. While a DMARC "reject" policy is not explicitly required by GDPR.

Use DMARC in your large organizations to stop domain spoofing at scale. For global enterprises operating in the UK, EU, and US, this is foundational for phishing and BEC prevention, brand protection, compliance, and reliable delivery across Microsoft 365 and Google Workspace.

Big environments rarely have a single sender. You run multiple brands, regions, and subsidiaries, plus marketing platforms, CRMs, and ticketing systems. Mergers and acquisitions add legacy domains. Without clear inventory and staged controls, DMARC rollouts stall, and legitimate mail can fail alignment.

Discover every sender across primary and long tail domains. Separate critical traffic from marketing or regional flows.

Stabilize at p=none, review aggregate reports, and fix SPF or DKIM alignment. Subdomain delegation helps reduce risk.

Progress to p=quarantine for lower risk streams first, then expand to high value flows once alignment holds steady.

Reach p=reject when failure rates are low and known. Keep alerting in place for new or unexpected sources.

Operate and audit with key rotation, change tracking, and executive reporting to meet UK, EU, and US standards.

An enterprise grade DMARC platform, such as Red Sift OnDMARC, accelerates this journey with automated sender discovery, prescriptive fixes, anomaly detection, and role based access for global teams. It surfaces the small set of actions that move you forward, turns XML data into clean insights, and manages multi domain policy at scale. The result is faster time to enforcement, fewer blind spots, and consistent governance across business units.

DMARC for small and medium businesses (SMBs)

SMBs are frequent targets for spoofing and invoice fraud. By implementing DMARC you benefit from stopping phishing attempts that appear to come from you, stronger customer trust, reduced cyber risk and compliance with new bulk senders Google, Yahoo and Microsoft.

You rely on a handful of tools, often without a dedicated security team. The common blockers are fear of breaking email, limited time, and unreadable XML reports. You need a guided path, clear steps, and alerts that tell you exactly what to change.

Set up SPF, DKIM, and DMARC for your primary domain and any sending tools, then run at p=none.

Monitor for a few weeks, fix alignment issues for newsletters, invoices, and CRM messages.

Move to p=quarantine once failure rates are low. Check for bouncebacks or missing alignments.

Advance to p=reject when you see stable results.

Keep watch with lightweight alerts, quarterly checks, and DKIM key rotation.

A guided DMARC platform, for example Red Sift OnDMARC, discovers who sends on your behalf, provides exact SPF and DKIM changes, and recommends when to shift policy. Dashboards make it obvious when a new tool starts sending or something fails alignment, so you fix issues fast without deep email expertise.

Learn how DMARC works, why it stops spoofing, and how to reach enforcement. Definitions, steps, and best practices.

What Is DMARC? | Plain-English Guide from Red Sift

What is DMARC?

Global mandates and guidance for DMARC in 2025

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

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.

We've created a table summarizing global DMARC mandates and guidance, offering a clear and unified overview of regional requirements.

Global mandates and guidance for DMARC

Why choose Red Sift for your email security

Founded in 2016, the Red Sift Platform was built as a direct response to the challenges many global organizations were facing when trying to fix vulnerabilities in their cyber infrastructure. 

Red Sift OnDMARC, an automated DMARC application, was the first product to launch on the Platform. It enables businesses all over the globe to easily, quickly, and safely implement DMARC, thus protecting business email communications with customers, suppliers, and partners by blocking vendor fraud, account takeovers, and email spoofing. 

Everything within OnDMARC is designed to save you time and simplify your DMARC journey as you fully secure your domain.

Our powerful automation does all the heavy lifting by continuously analyzing what’s going on across your domain, surfacing alerts for where and how to make necessary changes to your email security. Then simply follow our extensive database with setup instructions for hundreds of well-known email sources.

Full visibility into your sending sources

Within 24 hours of adding your unique DMARC record to your DNS, OnDMARC begins to analyze and display your DMARC reports in clear and comprehensive dashboards. Who is sending on your behalf? Where in the world is your domain being used? Are your emails passing or failing DMARC validation? This gives a complete picture of your email landscape and not just the stuff that crosses your network boundary.

Relying on consultants is a time-consuming process to configure DMARC, leaving you with no ongoing visibility or knowledge of how it works, which may mean calling them again! One of the most commonly reported benefits of OnDMARC is an average time of 6-8 weeks to reach full enforcement.

Once you’ve hit the switch to p=reject, it’s time to celebrate all those blocked impersonation attempts! If any of your defenses break, we’ll alert you of the root cause and provide instructions on how to fix it.

Red Sift’s Customer Success team is here to make setting up and maintaining your DMARC protection as simple and hassle-free as possible. We have a team of specialists available to help you with your DMARC project, from implementation to full in-life management so you can choose the level of support that works for you.

Red Sift CSEs are experienced in the most complex DMARC implementations at companies like Capgemini, ZoomInfo, and Wise, amongst others. Red Sift’s Customer Success is highly regarded by its enterprise customers, including Holland and Barrett, ZoomInfo, and TalkTalk.

Explore our full library of customer case studies here.

Red Sift OnDMARC’s Dynamic Services allows you to control your email records from within the OnDMARC app. In other words, there’s no need to return to your DNS provider to update any email authentication-related records. Instead, this is done by replacing the static DNS records with OnDMARC’s smart records, either via NS delegation for DKIM and DMARC or a new smart TXT record for SPF.

OnDMARC’s Dynamic SPF feature solves the 10 lookup limit by enabling you to use a single dynamic include to combine all authorized services correctly at the point of query. This prevents your authorized traffic from failing SPF validation and means your email deliverability will never be impacted. 

What makes Red Sift OnDMARC different from all other tools on the market is its Investigate feature. It allows you to test configuration updates in real-time rather than waiting for DMARC data to arrive over 24 hours, drastically reducing the time needed for a DMARC project and speeding up the time needed until full protection is reached. 

DNS Guardian actively monitors your domains for DNS misconfigurations that could lead to domain takeovers. This includes safeguarding against SubdoMailing, dangling DNS records, and CNAME takeovers.

Unique to the market, Red Sift OnDMARC is the only DMARC application that bridges the gap between DNS and DMARC in this way.

To learn more about the feature and how these types of DNS attacks bypass DMARC protections, read our blog.

Red Sift OnDMARC’s BIMI feature is the only integrated BIMI and Verified Mark Certificate (VMC) solution available on the market. It guides you through the full BIMI application process and even helps you obtain a VMC without having to go directly to the Certificate Authority (CA). Issuing VMCs has historically been a tedious process but Red Sift’s integrated process aims to make it easier.

BIMI implementation with Red Sift includes end-to-end support from its Customer Success team. Another advantage is that a free VMC license is included in OnDMARC’s Enterprise tier so organizations don’t need to secure additional budget for BIMI.

Hosted MTA-STS is part of OnDMARC’s Dynamic Services interface. After you have added Smart Records to your domain’s DNS, it will host the MTA-STS policy file, maintain the SSL certificate, and flag any policy violations through the TLS report.

Forensic reporting and machine learning provides granular information on unauthenticated emails while protecting privacy. Red Sift is one of only two DMARC vendors on the market who boast the Yahoo forensics feed that enhances forensic reporting. 

OnDMARC has a REST API that can be used to integrate with your custom dashboards and other internal systems. All endpoints are documented here with working examples; from managing every aspect of Dynamic Services and your email sources to creating your own charts from reporting data. You can also add and remove domains, configure alerts, or analyze any domain programmatically.

Today, we have over 1,000 customers including some of the most recognized brands in the world, such as Capgemini, Domino’s, ZoomInfo, Athletic Greens, Telefonica, and Wise.

The company has strategic partnerships with Google, Microsoft, IBM, and Entrust. From November 2023, Red Sift is the new partner for Cisco Domain Protection.

Red Sift is deeply committed to quality with the following quality and security accreditations:

Members of CyberExchange and Global Cyber Alliance

Data centers in the UK, EU and USA for data residency requirements

We hope that you found this guide a useful way to start building your understanding of DMARC and all its security benefits. We appreciate it’s a lot to take in but remember, if you can find yourself a trusted and proven DMARC provider, you’ll have an expert by your side for your whole DMARC journey, making it easier, faster, and painless.

Find out why over 1,200+ global brands trust Red Sift OnDMARC to help them stay protected from phishing and spoofing attacks.

Why choose Red Sift for your email security?

Thanks for your request.

I have read and accepted the Terms and Conditions and Privacy Policy and consent to receive Red Sift communications.

Become a partner

Become a Partner

Red Sift’s definitive guide to email security

#ED1651

Red Sift's comprehensive guide to help both beginners and buyers with their email security related queries.

Red Sift’s Definitive Guide to Email Security

Resources

Company

Protect against phishing and BEC attacks.