Column

Imagine if an important business message or a newsletter you put your heart into creating ended up in the recipient’s “Junk” folder. In fact, this problem is almost always caused not by the content of the email, but by the sender domain authentication configured in the DNS (Domain Name System). The DNS is a system that links domains to servers on the Internet, and it also serves as the foundation for determining the reliability of emails. In February 2024, Google significantly strengthened its sender guidelines. Businesses sending more than 5,000 emails per day are now required to implement all three of the following: SPF, DKIM, and DMARC. Furthermore, starting in January 2025, NTT Docomo will begin gradually displaying “spoofed email warnings” on emails that do not have sender domain authentication enabled. We are now entering an era where emails with incorrectly configured DNS settings simply won’t be delivered. However, there are likely quite a few people who are thinking, “SPF? DKIM? DMARC? What are those? I don’t really understand.” In this article, we’ll provide a thorough explanation of how these three technologies work, how they differ, and how to configure DNS—all presented in a way that’s easy to understand even for those with zero technical knowledge. Why is “sender domain authentication” necessary right now? Damage caused by phishing emails is increasing year by year, leading to financial losses for companies, data breaches, and even damage to their brand reputation. The sender domain authentication technologies known as SPF, DKIM, and DMARC are designed to counter these threats. SPF is a mechanism that verifies whether the sending server is legitimate. DKIM applies a digital signature to emails to verify “whether the email is a spoof” and whether the content has been tampered with. DMARC is a policy that determines how to handle emails that fail SPF or DKIM authentication based on the results of those checks. By configuring these technologies properly, you can significantly reduce the risk of spoofed emails. Let’s take a closer look at their importance. The Current State of Phishing Emails In recent years, damage caused by “phishing emails”—which impersonate real companies or individuals—has surged. There are cases where emails posing as business partners infect recipients with malware (a general term for software created for malicious purposes), leading to the leakage of personal information, or where emails instructing recipients to transfer funds to fake bank accounts result in financial fraud. What makes spoofed emails so sophisticated is that, from a technical standpoint, the “From” address can be freely altered. Attackers impersonate legitimate company domains to send emails that appear completely legitimate at first glance. It is extremely difficult for humans to distinguish these from genuine emails, which is precisely why incidents continue to occur. Furthermore, phishing emails pose a direct risk of brand damage. If your company’s domain is misused to send large volumes of phishing emails, it could significantly erode recipients’ trust. Furthermore, this could cause legitimate emails to be filtered into the spam folder, potentially disrupting important communications with customers. Impact of Gmail Sender Guidelines In February 2024, Google strengthened its “Sender Guidelines.” The guidelines are summarized as follows: Mandatory for all senders: Compliance with either SPF or DKIM. High-volume senders (5,000 or more emails per day): Compliance with all three—SPF, DKIM, and DMARC. Failure to comply may result in emails failing to reach Gmail users. Furthermore, in practice, DKIM is becoming virtually mandatory even for non-high-volume senders, as emails without DKIM are highly likely to be flagged by Gmail’s spam filter. [Reference] Gmail, “Guidelines for Email Senders”; NTT Docomo’s “Phishing Email Warning” Starting in January 2025, NTT Docomo began gradually displaying “phishing email warnings” for emails that do not comply with sender domain authentication. For businesses that send emails to individual users, compliance has become an urgent priority. [Reference] NTT DOCOMO, “Spoofed Email Warning Display” Return to Table of Contents How Are Emails Sent? (The Basics) To understand sender domain authentication, the first thing you need to know is the difference between the “Envelope From” and the “Header From.” The mechanism of email is easiest to understand by comparing it to the relationship between an envelope and a letter. Envelope From (Sender on the Envelope) This is the sender for delivery purposes. In postal terms, it’s the name written on the envelope. It is not displayed on the recipient’s screen. Header From (Sender in the Header) This is the sender displayed on the screen. The “sender information” we see on our email inbox screen refers to this one. Spammers exploit this. The Basic Structure of Email (Envelope From and Header From) Even if the sender on the envelope and the sender of the letter are different, the email will still be delivered. It’s also possible to change only the name that is displayed. For example, an email can be sent from one location while appearing to come from “info@大手銀行.co.jp.” This is the technique used in spoofed emails. SPF, DKIM, and DMARC are mechanisms designed to prevent this problem. For now, just remember that “there are two senders.” Back to Table of Contents What is SPF? (A Mechanism for Verifying the Sender’s IP) The first step in preventing spoofing is SPF. This is a mechanism where you register the servers authorized to send emails from your domain with DNS. When Gmail receives an email, it verifies whether the sender is legitimate. Let’s start by understanding this “sender verification” mechanism. Basic Concepts of SPF SPF (Sender Policy Framework) is a system that allows you to pre-register in DNS which servers are authorized to send emails from a given domain. For example, you would pre-register information in the DNS such as, “Emails from example.com are sent only from the server with IP address 203.0.113.1 (*for illustrative purposes only).” The recipient checks whether the IP address of the server that actually sent the email is included in that registered list. If the email is sent from an IP address not on the list, it can be judged as “potentially spoofed.” How SPF Works The SPF verification process follows these steps: The sender sends the email. The receiving server records the IP address of the server from which the email arrived. It queries DNS using the domain in the envelope “From” field (e.g., example.com). It compares the SPF record in the DNS TXT record with the actual sending IP address. If they match, the result is “SPF authentication successful (Pass)”; if there is a mismatch, it is judged as “Fail/SoftFail.” How SPF Works: The receiving server references DNS to verify the IP address. How to Read SPF Records (Reference) The actual SPF record is written in a DNS TXT record as follows: v=spf1 include:spf.google.com ip4:203.0.113.1 ~all Meaning of each element v=spf1: Declaration of SPF version 1 include:spf.google.com: Allow messages sent from Google’s mail servers (when using external services such as Gmail) ip4:203.0.113.1: Permits sending from this IP address ~all: Treats anything other than the above as a “SoftFail” (warning) (-all results in a complete rejection) The difference between ~all and -all lies in the severity of the response to an SPF failure. While -all (HardFail) recommends complete rejection, it is often recommended to start with ~all and monitor the situation, as legitimate emails may be falsely flagged when forwarding messages. Limitations of SPF Reading this far, you might think, “If I configure SPF, I can prevent spoofing.” However, SPF alone is not sufficient. In fact, SPF has structural weaknesses that are simply unavoidable. Does not verify the “From” header: SPF verifies the envelope “From” (the sender on the envelope). It does not verify the “From” header displayed in email clients (the sender of the message). In other words, SPF alone cannot prevent spoofing where the “Envelope From” is set to the legitimate domain, but the “From” header is forged. Cannot Handle Forwarding When an email is forwarded, the IP address of the forwarding server becomes the new “sender IP.” However, since the forwarding server’s IP is not registered in the SPF record, SPF authentication fails even though the email is legitimate. DKIM, which we’ll explain next, was introduced to address these weaknesses. Back to Table of Contents What is DKIM? (Digital Signature for Tamper Prevention) If SPF is a mechanism for verifying the “sending server,” the next step is a mechanism to verify whether “the email itself is authentic.” This is where DKIM comes in. Basic Concept of DKIM If SPF is a “list of authorized sending servers,” then DKIM is a “seal of authenticity.” The concept of DKIM is similar to affixing a company seal to an important document. The sender applies an “electronic signature” to the email, and the recipient verifies that signature to confirm that “this email was created by the genuine sender and has not been tampered with in transit.” How DKIM Works DKIM is a mechanism for applying an “electronic signature” to emails. While SPF verifies the sender’s IP address, DKIM verifies whether “the email was sent from a legitimate source (not a spoof)” and whether “the email’s content has not been tampered with.” DKIM operates using digital signatures based on public-key cryptography. The sender’s process is carried out as follows: Calculate a hash value from the email’s contents (headers + body). Encrypt the hash value with a private key to create a “signature.” Add the signature to the email as a DKIM-Signature header and send it. * A hash value is a fixed-length string generated by applying a special calculation (a hash function) to data; it is produced through a one-way (irreversible) transformation that cannot be reversed. The recipient’s process is carried out as follows: Retrieve the signing domain (d=) and selector (s=) from the DKIM-Signature header. Retrieve the public key from DNS. Decrypt the signature using the public key to extract the hash value. Verify that it matches the hash value of the received email body. *d= (signing domain) refers to the domain name that signed the email. This means “This domain is responsible.” *s= (selector) is the name (identifier) used to locate the public key. It allows a single domain to use multiple keys. How DKIM Works: Detects email tampering using digital signatures based on public-key cryptography. If the values match, “DKIM authentication succeeds,” confirming that the email has not been tampered with and was created by the authentic sender. Contents of the DKIM-Signature (for reference) The DKIM-Signature actually added to the email header has the following structure: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=example.com; s=google; …omitted… bh=hash value; b=signature data Main parameters d= (domain): The domain that performed the signature. Important values used for DMARC alignment checks: s= (selector): The key used to look up the public key via DNS. a= (algorithm): The signing algorithm (rsa-sha256 is common). What is a selector? A selector is an identifier used to distinguish between multiple DKIM key pairs within a single domain. For example, if d=example.com and s=google, the receiving server will look up the DNS record google._domainkey.example.com to retrieve the public key. This allows you to manage multiple email services using separate selectors. Mechanism for Using Different Keys Across Multiple Services Limitations of DKIM It is often assumed that if SPF and DKIM are configured, “spoofing protection is complete.” However, DKIM also has weaknesses. Replay Attacks: DKIM cannot prevent “replay attacks,” in which a malicious third party intercepts an email with a valid DKIM signature and resends it to a different recipient. No Policy Control on Its Own: While DKIM verifies authenticity, it does not define policies for how to handle emails that fail authentication. DMARC handles the response to authentication failures. DKIM is a mechanism for verifying “authenticity.” However, it cannot determine how to handle emails that fail authentication. That role is fulfilled by DMARC, which we’ll explain next. Back to Table of Contents What Is DMARC? (The Command Center That Makes the Final Decision) SPF and DKIM now allow us to verify the “sender” and “whether the message has been tampered with.” But what happens to an email if either of these checks fails? DMARC is responsible for making that final decision. The Role of DMARC DMARC (Domain-based Message Authentication, Reporting, and Conformance) is the command center that receives the “results” from SPF and DKIM and determines how to handle emails that fail authentication. DMARC has the following three roles. Final Determination: It comprehensively assesses the authenticity of an email by combining the SPF and DKIM authentication results with alignment (discussed later). Policy Declaration: Specifies how the receiving server should handle emails when authentication fails. Receiving Reports: Allows you to receive aggregated reports showing who is sending emails from which domains. DMARC Policy: A DMARC record is a “rule for handling email” configured in DNS. It is displayed as follows: v=DMARC1; p=none; The “p” in the DMARC record stands for “policy” and specifies how to handle emails that fail authentication. Three Policy Levels DMARC allows you to set three policy levels. Policy Meaning Recommended Use none Monitoring only. Does not affect email processing. Initial investigation and monitoring phase. quarantine Sorts emails that fail authentication into the spam folder. Intermediate stage. reject Completely rejects emails that fail authentication. Full-scale operation. Reasons for a Phased Implementation You should not set DMARC to “reject” right away. There are two reasons for this. First, if you set the policy to “reject” without fully understanding all legitimate email delivery paths, even legitimate emails sent from newsletter services, internal systems, and external applications will be rejected. Second, if you set the policy to “reject” while SPF and DKIM configurations are incomplete, a large number of legitimate emails may be rejected. Recommended Steps: Start monitoring with `p=none` (use DMARC reports to identify sending paths). Once SPF and DKIM are configured for all paths, transition to `p=quarantine`. If no issues are found, escalate to `p=reject`. An important concept called “alignment” is involved in DMARC decisions. Next, let’s take a closer look at how this works. Return to Table of Contents What Is DMARC “Alignment”? So far, we’ve examined how SPF, DKIM, and DMARC work. However, there are cases where “authentication succeeds but DMARC fails.” The cause of this is alignment mismatch. Why Is Alignment Important? Alignment is a mechanism that verifies whether the domain used for authentication matches the sender (From) displayed on the screen. DMARC performs this check against both SPF and DKIM. SPF Alignment: SPF verifies the domain of the “envelope From” (Envelope From). DMARC checks whether the domain that passed SPF authentication matches the displayed “From” (Header From) domain. DKIM Alignment: DKIM verifies the “d=domain” included in the signature. DMARC checks whether the DKIM signature was successful and whether that “d=domain” matches the displayed “From” (header “From”) domain. The Difference Between “Relaxed” and “Strict” “Relaxed” and “Strict” are settings that determine the strictness of the alignment (domain match) check. They are specified within the DMARC record. “Relaxed” is a lenient check that allows subdomains, while “Strict” is a strict check that permits only exact matches. Unless there is a specific reason, using “Relaxed” is generally sufficient. DMARC is Valid if Either Condition is Met It is important to note that DMARC is considered a “PASS” (successful) if either the SPF alignment or the DKIM alignment passes. This means that even in cases where SPF authentication fails—such as when emails are relayed—DMARC will still pass as long as DKIM alignment passes. That is why it is crucial to “configure both SPF and DKIM.” Illustrated Guide to How DMARC Works Return to Table of Contents Frequently Asked Questions Here, we address some frequently asked questions. Q. Why does it end up in the spam folder? A. If SPF or DKIM is not configured or is configured incorrectly, the recipient’s mail server will deem the sender “untrustworthy” and route the email to the spam folder. Gmail, in particular, strictly handles emails that are not DKIM-signed. Q. Can “display name” spoofing be prevented? A. SPF, DKIM, and DMARC cannot prevent “display name” spoofing. For example, even if the actual sender is evil.com, as in “Taro Yamada attacker@evil.com,” the display name in the email client can be spoofed to appear as “Taro Yamada.” Implementing BIMI (Brand Indicators for Message Identification) is an effective countermeasure against display name spoofing. Q. Why does SPF authentication fail when an email is forwarded? A. When an email is forwarded, the forwarding server becomes the new “sender IP address.” However, since the forwarding server’s IP address is not registered in the original sender’s SPF record, SPF authentication fails. To work around this, the “SRS (Sender Rewriting Scheme)” mechanism rewrites the envelope “From” field during forwarding to ensure SPF authentication passes. DKIM is resistant to forwarding because the signature remains valid as long as the email body and headers are not altered during forwarding. Back to Table of Contents Summary In this article, we explained the mechanism of “sender domain authentication,” which is a common cause of emails ending up in the spam folder. SPF (Sender Policy Framework): A mechanism that declares the sender’s IP address via DNS to detect spoofed emails. While configuration is relatively simple, it has the limitation that it does not verify the “From” header, so there are cases where emails fail authentication due to forwarding. DKIM (DomainKeys Identified Mail): Uses digital signatures to verify the authenticity of an email and ensure it has not been tampered with. It is robust against forwarding and can also verify the “From” header domain. DMARC (Domain-based Message Authentication, Reporting, and Conformance): A mechanism that uses the results of SPF and DKIM to declare how to handle authentication failures (none/quarantine/reject) and receive reports. It is considered valid if either SPF or DKIM alignment passes. These three work together as a set. Each one alone is insufficient; only when combined do they form a robust sender domain authentication system. Start by “configuring SPF and DKIM” and “beginning DMARC monitoring with p=none.” Check out learningBOX’s feature list and pricing table now! Download materials ▼ You might also like! Related articles