How Email Authentication Works: DNS Level

Have you ever wondered how your inbox manages to filter out the spam and deliver genuine emails accurately? It’s not magic; it’s the meticulous work of email authentication protocols, primarily operating at the DNS level. As a sender, ensuring your emails reach their intended recipients and aren’t flagged as suspicious is paramount. As a recipient, you want assurance that the email you’re reading actually came from the purported sender. This article will guide you through the intricate world of email authentication, specifically focusing on the foundational role of DNS records.

Imagine sending a physical letter. You write the return address on the envelope, and the postal service uses that to verify your identity and, if necessary, return the letter. Email, however, is far more complex and prone to impersonation. Without robust authentication, anyone could claim to be you, your bank, or a major corporation, sending malicious emails with impunity. This is where DNS-level authentication steps in, providing a digital equivalent of that verifiable return address, but with cryptographic assurances.

You see, the core problem email faces is that the “From” address you see in your email client (the “header From” or RFC5322.From) can be easily faked. This is similar to writing any return address you wish on an envelope. What DNS authentication does is verify the owner of the domain attempting to send the email, linking it to the email’s actual sending infrastructure. This verification happens behind the scenes, long before the email even reaches your inbox’s spam filter based on content.

The Problem of Email Spoofing

You’re likely familiar with phishing scams. These often rely on email spoofing, where an attacker crafts an email that appears to originate from a legitimate source, like your bank or a well-known service. You open the email, click a malicious link, and suddenly your credentials are compromised. The fundamental vulnerability that allows spoofing is the ability to manipulate the “From” address. Without DNS authentication, there’s no reliable way for the receiving server to discern whether the sender is who they claim to be.

The Need for Trust and Deliverability

As a sender, your email deliverability directly impacts your business. If your legitimate emails are constantly being marked as spam or rejected outright because of a lack of proper authentication, you’re losing valuable communication with your customers and prospects. Conversely, recipients need to trust the emails they receive. DNS-level authentication builds this trust by making it significantly harder for malicious actors to impersonate legitimate domains, thereby protecting users from phishing, malware, and other cyber threats.

For a deeper understanding of how email authentication operates at the DNS level, you may find the article on “Understanding SPF, DKIM, and DMARC: The Triad of Email Authentication” particularly insightful. This resource provides a comprehensive overview of the key protocols involved in securing email communications and how they interact with DNS records to prevent spoofing and phishing attacks. You can read it here: Understanding SPF, DKIM, and DMARC: The Triad of Email Authentication.

SPF: The Sender Policy Framework – Declaring Your Authorized Senders

Think of SPF as a public declaration, published in your domain’s DNS, that lists all the IP addresses and mail servers authorized to send emails on behalf of your domain. When a mail server receives an email claiming to be from your domain, it consults your SPF record to verify if the sending IP address is on your approved list. This is your first line of defense against unauthorized senders.

When you send an email, your sending mail server establishes a connection with the recipient’s mail server. During this connection, the sending server identifies itself with a “MAIL FROM” address (also known as the “envelope sender” or RFC5321.MailFrom). This address is crucial for SPF validation.

How an SPF Record is Constructed

Your SPF record is a TXT record in your DNS. It starts with “v=spf1”, indicating the version of SPF being used. Following this, you specify the mechanisms that define authorized senders.

Common SPF Mechanisms

• a: Authorizes the A records of the current domain. If your domain’s A record points to your mail server’s IP, this authorizes that IP.
• mx: Authorizes the MX records of the current domain. This means any server listed as an MX record for your domain is authorized to send email.
• ip4 / ip6: Explicitly authorizes specific IPv4 or IPv6 addresses or ranges. For example, ip4:192.0.2.1 or ip4:198.51.100.0/24.
• include: Allows you to include SPF records from other domains. This is incredibly useful when you use third-party email services (like Google Workspace, Microsoft 365, Mailchimp, SendGrid) to send emails on your behalf. For example, include:_spf.google.com.
• exists: A more advanced mechanism that queries DNS for A records.
• redirect: Similar to include but replaces the current SPF record entirely with linked domain’s SPF.

SPF Qualifiers: What to Do with a Mismatch

Each mechanism can have a qualifier that dictates the action to be taken if a match or mismatch occurs:

• + (Pass): Explicitly authorizes the sender. This is the default if no qualifier is specified (e.g., a is equivalent to +a).
• - (Fail): Explicitly designates the sender as NOT authorized. This is a strong signal that the email should be rejected or marked as spam. For example, -all.
• ~ (SoftFail): Designates the sender as NOT authorized, but with a less strict action. The email might be accepted but marked as suspicious. For example, ~all.
• ? (Neutral): Declares no opinion about the sender. The receiving server can decide what to do. For example, ?all.

The most common and recommended qualifier at the end of an SPF record is ~all or -all. ~all suggests that any server not explicitly listed is probably not authorized but leaves room for interpretation, while -all definitively states that only listed servers are authorized. Most organizations start with ~all and move to -all once they are confident all their sending sources are accounted for.

The SPF Check Process

When an email arrives at a recipient server, the following SPF check takes place:

1. Extract MAIL FROM: The receiving server identifies the “MAIL FROM” address from the email’s envelope.
2. Query DNS: It then performs a DNS query for a TXT record on the domain extracted from the “MAIL FROM” address.
3. Evaluate SPF Record: The server evaluates the mechanisms in the SPF record against the IP address of the connecting mail server.
4. Determine Result: Based on the qualifiers and mechanisms, a result is determined: Pass, Fail, SoftFail, Neutral, TempError, PermError.
5. Action: The recipient server uses this result (along with other factors) to decide whether to accept, reject, or mark the email as spam.

SPF Limitations

While powerful, SPF has some limitations:

• Breaks with Forwarding: If an email is forwarded (e.g., from [email protected] to [email protected]), the onward sending server might not be authorized by the original sender’s SPF record. This can lead to legitimate emails being flagged.
• Only Authenticates the Envelope Sender: SPF only verifies the MAIL FROM address, not the Header From address that your users actually see. This means an attacker can still spoof the visible “From” address, even if the SPF passes, if they control a domain whose SPF allows them to send mail. This is why DKIM and DMARC are essential.
• 10-Lookup Limit: An SPF record can only include up to 10 DNS lookups (e.g., from include or mx mechanisms). Exceeding this limit will cause SPF to return a PermError, making your SPF record invalid and potentially impacting deliverability.

DKIM: DomainKeys Identified Mail – Digital Signatures for Email Integrity

DKIM adds a cryptographic layer of authentication, bringing a digital signature to your emails. While SPF verifies the sender’s identity, DKIM verifies the email’s integrity and that it hasn’t been tampered with since it left the authorized sender. It’s like a tamper-proof seal on your physical letter. DKIM addresses SPF’s limitation of only authenticating the envelope sender and being susceptible to forwarding issues.

When you enable DKIM for your domain, your outgoing mail server generates a unique digital signature for each email it sends, based on specific parts of the email (like the header and some of the body). This signature is then inserted into the email’s header. Concurrently, you publish a public key in your DNS records.

How DKIM Works with Public and Private Keys

DKIM relies on public-key cryptography. You have a pair of keys:

• Private Key: This key is kept secret on your mail server. It’s used to generate the digital signature for outgoing emails.
• Public Key: This key is published as a DNS TXT record for your domain. Recipient mail servers use this public key to verify the digital signature.

The DKIM Signature Header

A DKIM signature is added to the email’s header, typically looking like this:

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yourdomain.com; s=selector; h=from:to:subject:date; bh=base64hash; b=digital_signature;

Let’s break down some key parts:

• v=1: DKIM version.
• a=rsa-sha256: Algorithm used for signing (RSA with SHA-256 hash).
• c=relaxed/relaxed: Canonicalization algorithm for headers and body. This dictates how whitespace and header casing are handled before signing/verification, making the signature more resilient to minor modifications.
• d=yourdomain.com: The signing domain – the domain responsible for signing the email.
• s=selector: A specific hostname under your domain where the public key is found. This allows you to have multiple DKIM keys for different mail streams or third-party senders. For example, selector._domainkey.yourdomain.com.
• h=: A list of email headers that were included in the signature. This ensures that these specific headers haven’t been altered.
• bh=: The hash of the email body.
• b=: The actual digital signature.

The DKIM Verification Process

When an email with a DKIM signature arrives at a recipient server:

1. Locate Signature: The recipient server finds the DKIM-Signature header in the email.
2. Extract Information: It extracts the signing domain (d=) and the selector (s=) from the signature.
3. Query DNS for Public Key: It constructs a DNS query using the selector and signing domain (e.g., selector._domainkey.yourdomain.com) to retrieve the public key.
4. Verify Signature: Using the retrieved public key, the algorithm specified (a=), the canonicalization rules (c=), and the hashed headers (h=) and body (bh=), the recipient server attempts to decrypt the digital signature (b=).
5. Determine Result: If the signature successfully decrypts and matches the email’s content, DKIM passes. If there’s a mismatch or no key found, it fails.
6. Action: The result of the DKIM check (along with SPF and other factors) influences the email’s fate (delivery, spam folder, rejection).

Advantages of DKIM

• Authenticates the “Header From” Domain: Crucially, DKIM can authenticate the visible “From” address, which SPF historically struggled with. This means if the d= tag in the DKIM signature matches the domain in the Header From address, it provides a strong assurance that the email truly came from that organization.
• Resistant to Forwarding: Because the signature is embedded in the header and verifies the content, DKIM generally survives email forwarding without breaking, unlike SPF.
• Tamper Detection: Any alteration to the signed parts of the email (headers or body) after it was signed will cause the DKIM signature to fail verification, indicating potential tampering.

DKIM Limitations

• Complexity: Setting up and managing DKIM can be more complex than SPF due to key generation, selector management, and ensuring all sending services are signed correctly.
• Not a Standalone Solution: While powerful, DKIM alone doesn’t tell a receiving server what to do with a failed email. It simply reports a pass or fail. This brings us to DMARC.

DMARC: Domain-based Message Authentication, Reporting, and Conformance – Orchestrating Authentication

DMARC acts as the conductor of your email authentication orchestra. It tells receiving mail servers what to do when SPF and/or DKIM checks fail, and it provides a feedback loop that sends reports back to the domain owner about authentication results. DMARC ties SPF and DKIM together by introducing the concept of “alignment” and then specifies policies for handling unauthenticated messages.

You’ve successfully implemented SPF and DKIM. Now, how do you tell the world what to do when an email claiming to be from your domain fails these checks? And how do you get visibility into who is trying to impersonate your domain? That’s DMARC’s role.

The Two Pillars of DMARC: Alignment and Policy

DMARC builds upon SPF and DKIM with two core concepts:

1. DMARC Alignment

For DMARC to pass, either SPF or DKIM (or both) must pass and establish “alignment” with the “Header From” domain.

• SPF Alignment: The domain in the MAIL FROM address (envelope sender) must exactly match or be a subdomain of the Header From domain.
• Strict Alignment: Requires an exact match of the MAIL FROM domain and the Header From domain.
• Relaxed Alignment: Allows the MAIL FROM domain to be a subdomain of the Header From domain (e.g., mail.yourdomain.com and yourdomain.com).
• DKIM Alignment: The d= domain in the DKIM signature must exactly match or be a subdomain of the Header From domain.
• Strict Alignment: Requires an exact match of the DKIM d= domain and the Header From domain.
• Relaxed Alignment: Allows the DKIM d= domain to be a subdomain of the Header From domain.

If either SPF passes with alignment or DKIM passes with alignment, then DMARC passes. If both fail alignment, DMARC fails.

2. DMARC Policy (p=)

This is the instruction you give to receiving mail servers on what to do with emails that fail DMARC authentication. Your DMARC policy is also published as a TXT record in your DNS, specifically at _dmarc.yourdomain.com.

The primary action you specify is with the p= tag:

• p=none (Monitoring Mode): This is the safest starting point. It tells receiving servers not to take any specific action on failed emails, but to send DMARC reports. This allows you to monitor your email traffic and identify legitimate sending sources before enforcing stricter policies.
• p=quarantine: Tells receiving servers to treat emails that fail DMARC as suspicious. This usually means placing them in the recipient’s spam or junk folder, but it’s up to the receiving server’s discretion.
• p=reject: This is the strongest policy. It instructs receiving servers to outright reject emails that fail DMARC authentication, preventing them from reaching the inbox at all. This is the ultimate goal for protecting your domain from spoofing.

Other Important DMARC Tags

In addition to p=, other tags in your DMARC record provide crucial functionality:

• v=DMARC1: Specifies the DMARC protocol version.
• rua=: Specifies an email address where aggregated DMARC reports should be sent. These XML reports provide a summarized view of authentication results for emails originating from your domain.
• ruf=: Specifies an email address where forensic/failure DMARC reports should be sent. These are detailed, per-message reports about emails that fail DMARC verification, including partial message content. (Often less used due to privacy concerns and volume.)
• adkim= / aspf=: Specifies the alignment mode (strict s or relaxed r) for DKIM and SPF, respectively. Default is r.
• pct=: Percentage of messages to apply the DMARC policy to (e.g., pct=10 means only 10% of failed emails will be subjected to the p= policy). Useful for gradually rolling out enforcement.

The DMARC Flow

When a recipient server receives an email:

1. Perform SPF check: Does the MAIL FROM domain’s SPF record authorize the sender’s IP?
2. Perform DKIM check: Is there a valid DKIM signature from the signing domain?
3. Check SPF Alignment: Does the MAIL FROM domain align with the Header From domain?
4. Check DKIM Alignment: Does the d= domain align with the Header From domain?
5. Evaluate DMARC Pass/Fail: If either SPF+alignment OR DKIM+alignment passes, DMARC passes. Otherwise, DMARC fails.
6. Apply DMARC Policy: If DMARC fails, the recipient server applies the policy defined in the sender’s DMARC record (p=none, p=quarantine, or p=reject).
7. Generate Reports: The recipient server generates aggregated reports (rua) and potentially forensic reports (ruf) and sends them to the specified addresses.

Benefits of DMARC

• Centralized Policy Enforcement: Provides a definitive policy for how receiving servers should treat unauthenticated emails from your domain.
• Visibility into Email Traffic: DMARC reports are invaluable. They show you who is sending email on behalf of your domain (both legitimate and illegitimate), which authentication checks are passing/failing, and from what IP addresses. This data is critical for identifying unauthorized senders and refining your authentication setup.
• Protects Your Brand: By moving to p=reject, you significantly reduce the ability of phishers and spoofers to use your domain to trick your customers or employees.
• Improved Deliverability: Domains with properly configured DMARC, especially at p=reject, are often viewed as more trustworthy by receiving servers, leading to better inbox placement.

DMARC Implementation Strategy

You should implement DMARC in a phased approach:

1. Start with p=none: This allows you to gather data from rua reports without impacting deliverability. Use a DMARC analytics tool to interpret these reports.
2. Identify all Legitimate Senders: The reports will reveal all entities sending email from your domain. Ensure each of these is properly authenticated with SPF (either by including their SPF record or adding their IPs) and DKIM.
3. Gradual Enforcement: Once confident that all legitimate emails are authenticated, gradually move to p=quarantine with pct=5, then pct=10, and so on, monitoring reports at each step.
4. Full Enforcement: When everything is correctly configured and all legitimate emails pass DMARC, move to p=reject. This is your ultimate goal for maximum protection.

Understanding how email authentication works at the DNS level is crucial for ensuring the security of your communications. For those looking to delve deeper into the topic, a related article that provides further insights is available. It explores the intricacies of various authentication methods and their implementation. You can read more about it in this informative piece on email authentication. This resource will help you grasp the importance of DNS records in protecting against phishing and spoofing attacks.

DNSSEC: Securing Your DNS Records – Preventing DNS Spoofing

Authentication Method	Description
SPF (Sender Policy Framework)	Specifies which IP addresses are allowed to send emails on behalf of a domain
DKIM (DomainKeys Identified Mail)	Uses cryptographic signatures to verify that an email message was not altered in transit
DMARC (Domain-based Message Authentication, Reporting, and Conformance)	Policy that specifies how to handle emails that fail SPF or DKIM checks

While SPF, DKIM, and DMARC secure your email using DNS, DNSSEC (DNS Security Extensions) secures DNS itself. DNSSEC adds cryptographic signatures to DNS records, ensuring that when a mail server queries your domain for an SPF or DKIM record, it receives authenticated and un-tampered-with data. Without DNSSEC, a sophisticated attacker could potentially intercept a DNS query, modify the SPF or DKIM record result, and trick the receiving server into accepting a spoofed email.

Imagine a secure vault (your DNS record like SPF or DKIM). DNSSEC is like the security cameras and tamper-evident seals on the vault itself. It ensures that no one has swapped out the vault’s contents (your record) without you knowing.

The Problem DNSSEC Solves: DNS Cache Poisoning

The DNS system is hierarchical and relies heavily on caching. When you visit a website, your computer queries a DNS resolver, which might query other nameservers until it finds the authoritative nameserver for that domain. The result is then cached. DNS cache poisoning is an attack where an attacker injects fraudulent DNS data into a resolver’s cache. If an attacker could poison the cache for your domain, they could redirect email authentication queries to their own rogue servers, thereby circumventing SPF, DKIM, and DMARC.

DNSSEC provides a way to verify the authenticity of the responses received from DNS servers.

How DNSSEC Works

DNSSEC introduces several new types of DNS records and a chain of trust model, built on public-key cryptography, similar to how DKIM uses it, but applied to DNS records.

• Digital Signatures (RRSIG records): Each standard DNS record (A, MX, TXT, etc.) and specific DNSSEC records has a corresponding RRSIG (Resource Record Signature) record. This signature is generated using a private key and can be verified using a public key.
• Key Records (DNSKEY records): These records contain the public keys for a zone. There are two main types:
• Zone Signing Key (ZSK): Used to sign the RRSIG records for other records within the zone.
• Key Signing Key (KSK): Used to sign the ZSK.
• Delegation Signer (DS records): These records are published in the parent zone (e.g., in the .com zone for yourdomain.com). A DS record for your domain contains a cryptographic hash of your domain’s KSK. This creates a “chain of trust” from the root of the DNS hierarchy down to your specific domain.

The DNSSEC Validation Process

When a DNSSEC-aware resolver queries for a DNS record (e.g., your SPF TXT record):

1. Request Record and Signature: The resolver requests the desired TXT record, along with its RRSIG record.
2. Request Public Keys: It also requests the DNSKEY records for your domain.
3. Verify RRSIG: It uses the ZSK (from the DNSKEY records) to verify the RRSIG of the TXT record. This confirms the record came from the authoritative nameserver and hasn’t been tampered with.
4. Verify Chain of Trust (KSK and DS): To trust the DNSKEY records themselves, the resolver looks for a DS record in the parent zone and uses the parent’s public key (retrieved through its own DNSKEY and DS records, and so on up to the root) to verify the DS record. This creates a continuous chain of cryptographic trust from the root name servers all the way down to your domain. If any link in this chain breaks, the validation fails, and the resolver rejects the response.

Benefits of DNSSEC

• Data Integrity and Authenticity: DNSSEC ensures that the DNS data you receive is exactly what the domain owner published and hasn’t been altered in transit or through cache poisoning.
• Protects Email Authentication Records: Since SPF, DKIM, and DMARC critically rely on DNS records, securing these records with DNSSEC adds another vital layer of protection against highly sophisticated attacks that could otherwise undermine your email authentication.
• Prevents Redirection Attacks: By verifying the authenticity of A and MX records, DNSSEC also helps prevent attackers from redirecting email to their own servers or redirecting web traffic to phishing sites.

DNSSEC Limitations and Complexity

• Complexity: Implementing DNSSEC is more complex than setting up basic DNS records. It involves managing keys, signing zones, and coordinating with your domain registrar and DNS provider.
• Not All Resolvers Are DNSSEC-Aware: While adoption is growing, not all DNS resolvers (especially older ones or those run by smaller ISPs) are DNSSEC-aware. If a resolver isn’t DNSSEC-aware, it won’t perform the validation checks.
• Key Management: Securely managing cryptographic keys (especially the KSK) is critical. Loss or compromise of a private key can have serious consequences.
• “Broken Chains”: If you don’t properly maintain your DS records with your registrar when you roll keys, you can “break the chain of trust,” making your domain appear unreachable to DNSSEC-validating resolvers.

While not directly part of email authentication protocols themselves, DNSSEC fortifies the very foundation upon which SPF, DKIM, and DMARC records reside. For organizations committed to the highest level of security, enabling DNSSEC is a logical and important step.

The Synergy of Authentication Protocols: A Layered Defense

You’ve explored SPF, DKIM, and DMARC individually, along with the foundational security DNSSEC offers. Now, it’s crucial to understand how these protocols work in concert to create a robust, layered defense against email fraud and enhance deliverability. No single protocol is a silver bullet; their true power lies in their combined application, orchestrated by DMARC.

Think of it as securing a high-value asset. You wouldn’t rely on just one lock for your vault, would you? You’d have multiple layers: a sturdy door, an alarm system, security guards, and surveillance cameras. Email authentication operates on a similar principle.

How Each Protocol Contributes

• SPF (Sender Policy Framework): Your initial gatekeeper. It checks the envelope sender (the MAIL FROM address) against a public list of authorized sending IP addresses in your DNS. It’s like checking the return address on the envelope against a list of approved individuals who can use that address. If SPF passes, it tells the recipient that the email originated from an authorized server for the envelope sender’s domain.
• DKIM (DomainKeys Identified Mail): Your tamper-proof seal and content authenticator. It cryptographically signs specific parts of your email (headers and body) using a private key and publishes a public key in your DNS. The recipient uses this public key to verify the signature. If DKIM passes, it tells the recipient that the signed parts of the email haven’t been altered since they left the signing domain’s server, and that the signing domain approved the message.
• DMARC (Domain-based Message Authentication, Reporting, and Conformance): The policy enforcer and intelligence gatherer. DMARC ties SPF and DKIM together by requiring alignment with the Header From domain you see in your email client. It then dictates a policy (p=none, p=quarantine, p=reject) for receiving servers to apply when both SPF and DKIM fail alignment. Crucially, it provides feedback reports (rua, ruf) allowing you to monitor and improve your authentication.
• DNSSEC (DNS Security Extensions): The integrity checker for the map itself. DNSSEC protects the very DNS records that SPF, DKIM, and DMARC rely on. It ensures that when a receiving server queries for your SPF, DKIM, or DMARC records, it receives genuine, untampered-with information, preventing DNS spoofing attacks that could undermine all other authentication efforts.

The Power of DMARC Alignment

The concept of DMARC alignment is what truly elevates the combined power of these protocols. Without alignment, an attacker could:

1. Pass SPF: By sending from a completely unrelated, legitimate-looking domain that has SPF configured, while spoofing your company’s Header From domain.
2. Pass DKIM: By signing the email with their own domain’s DKIM key, again while spoofing your Header From domain.

DMARC alignment closes these loopholes. It demands that at least one of these passed authentications (SPF or DKIM) must also verify the domain that the user actually sees in their email client – the Header From domain. This is critical because it’s the Header From domain that users rely on to identify the sender.

Example Synergy Walkthrough

Consider an email sent from [email protected]:

1. Email leaves server: Your mail server (IP: 192.0.2.5) sends an email with MAIL FROM:[email protected] and Header From: [email protected]. It also signs the email with your yourcompany.com DKIM key.
2. Recipient server receives email:

• DNS Query (DNSSEC protection): The recipient server first checks its DNSSEC status. If enabled, it validates the DNS records for yourcompany.com to ensure their authenticity. It queries for the SPF, DKIM public key, and DMARC records for yourcompany.com.
• SPF Check: It sees the connecting IP 192.0.2.5 and the MAIL FROM:[email protected]. It checks yourcompany.com‘s SPF record. If v=spf1 ip4:192.0.2.5 -all is there, SPF passes for [email protected].
• DKIM Check: It finds the DKIM signature with d=yourcompany.com and s=selector. It uses the selector._domainkey.yourcompany.com public key to verify the signature. If it decrypts correctly, DKIM passes for yourcompany.com.
• DMARC Alignment Check:
• SPF Alignment: The MAIL FROM domain is [email protected]. The Header From domain is [email protected]. This aligns (relaxed alignment, as bounce.yourcompany.com is a subdomain).
• DKIM Alignment: The DKIM d= domain is yourcompany.com. The Header From domain is [email protected]. This aligns (relaxed or strict, depending on configuration).
• DMARC Policy Application: Since SPF passed with alignment AND DKIM passed with alignment, DMARC passes. The email is delivered to the inbox.

Now, imagine a phisher sends an email spoofing [email protected] from their server (IP: 203.0.113.10):

1. Email leaves phisher’s server: MAIL FROM:[email protected], Header From: [email protected]. No DKIM signature from yourcompany.com.
2. Recipient server receives email:

• SPF Check: It sees MAIL FROM:[email protected]. It checks bad-domain.net‘s SPF record. Let’s say bad-domain.net does allow 203.0.113.10 to send, so SPF passes for bad-domain.net.
• DKIM Check: There’s no valid DKIM signature for yourcompany.com. DKIM fails.
• DMARC Alignment Check:
• SPF Alignment: The MAIL FROM domain is bad-domain.net. The Header From domain is [email protected]. These do not align.
• DKIM Alignment: DKIM failed, so there’s no DKIM alignment.
• DMARC Policy Application: Both SPF and DKIM fail alignment. DMARC fails. If yourcompany.com has a p=reject DMARC policy, the email is rejected. If p=quarantine, it goes to spam.

This illustrates why all three are essential. SPF prevents unauthorized use of the envelope sender, DKIM ensures message integrity and authenticates the signing domain, and DMARC forces alignment between these and the visible Header From domain, while also providing crucial policy and reporting capabilities. DNSSEC adds a layer of trust to all the DNS records these protocols rely on, ensuring your authentication settings cannot be tampered with.

By implementing all of these protocols carefully, you establish a strong, multi-layered defense that significantly protects your domain from email spoofing and enhances the deliverability and trustworthiness of your legitimate communications.

FAQs

What is email authentication at the DNS level?

Email authentication at the DNS level is a process that involves using DNS records to verify the authenticity of an email sender’s domain. This helps to prevent email spoofing and phishing attacks.

What are the common email authentication methods used at the DNS level?

Common email authentication methods used at the DNS level include SPF (Sender Policy Framework), DKIM (DomainKeys Identified Mail), and DMARC (Domain-based Message Authentication, Reporting, and Conformance).

How does SPF work at the DNS level?

SPF (Sender Policy Framework) works at the DNS level by allowing domain owners to specify which IP addresses are authorized to send emails on behalf of their domain. This information is published in the DNS records as a TXT record.

What is DKIM and how does it work at the DNS level?

DKIM (DomainKeys Identified Mail) is a method of email authentication that uses cryptographic signatures to verify the authenticity of an email message. At the DNS level, DKIM involves publishing a public key in the DNS records, which is used to verify the signature of the email.

How does DMARC enhance email authentication at the DNS level?

DMARC (Domain-based Message Authentication, Reporting, and Conformance) enhances email authentication at the DNS level by allowing domain owners to specify how their emails should be handled if they fail SPF or DKIM checks. It also provides reporting and feedback mechanisms to help domain owners monitor and improve their email authentication practices.