Why Email Authentication Is Essential Today<\/h2>\n\n\n\n![\"\"](\"https:\/\/learningbox.online\/wp-content\/uploads\/blog\/spoofing-protection-explanation-01-1024x538.jpg\")
<\/figure>\n\n\n\nDamage caused by phishing scams is increasing year by year, leading to corporate financial losses, data breaches, and severe brand reputation damage. The technologies known as SPF, DKIM, and DMARC were specifically developed to counter these threats.<\/p>\n\n\n\n
-SPF (Sender Policy Framework)<\/b> is a mechanism that verifies whether the sending server is legitimate.
-DKIM (DomainKeys Identified Mail)<\/b> applies a digital signature to emails to confirm that they originate from a legitimate sender and that the content has not been tampered with.
-DMARC (Domain-based Message Authentication, Reporting, and Conformance)<\/b> is a policy mechanism that determines how receiving servers should handle emails that fail SPF or DKIM authentication.<\/p>\n\n\n\n
By configuring these technologies correctly, you can prevent email spoofing while simultaneously improving your overall delivery rates. Let\u2019s look at each mechanism in detail.<\/p>\n\n\n\n
Current State of Email Spoofing<\/h3>\n\n\n\n
In recent years, damages caused by \"spoofed emails\" impersonating actual companies or individuals have been surging rapidly. Cases exist where emails pretending to be from business partners infect systems with malware (a general term for software created with malicious intent), causing personal data leaks, or where emails instructing transfers to fake bank accounts result in financial theft.<\/p>\n\n\n\n
What makes spoofed emails so insidious is that the sender's From address can be freely altered from a technical standpoint. Attackers forge the domain of legitimate companies to send emails that appear completely unsuspect. It is extremely difficult for the human eye to distinguish them, which is precisely why damages continue unabated.<\/p>\n\n\n\n
Furthermore, spoofed emails directly lead to the risk of brand reputation damage. If your company's domain is exploited to send massive amounts of phishing emails, there is a risk of severely damaging the trust of recipients. Additionally, as a consequence of this impact, even legitimate emails may be sorted into spam folders, potentially disrupting critical communication with customers.<\/p>\n\n\n\n
Impact of the Gmail Email Sender Guidelines<\/h3>\n\n\n\n
In February 2024, Google tightened its \"Email Sender Guidelines.\" The outline of the guidelines is as follows:<\/p>\n\n\n\n
Required for all senders<\/h4>\n\n\n\n
Implementation of either SPF or DKIM<\/p>\n\n\n\n
Bulk senders of 5,000 or more emails per day<\/h4>\n\n\n\n
Implementation of all three: SPF, DKIM, and DMARC<\/p>\n\n\n\n
If left unaddressed, emails sent to Gmail users may fail to be delivered. Furthermore, in practice, DKIM is becoming a virtually mandatory requirement even for non-bulk senders. This is because emails lacking DKIM are heavily flagged by Gmail's spam filters.<\/p>\n\n\n\n
[Reference] Gmail, \u201cGuidelines for Email Senders<\/a> <\/p>\n\n\n\nNTT DOCOMO\u2019s \"Spoofed Email Warning\"<\/h3>\n\n\n\n
Starting in January 2025, NTT Docomo began sequentially deploying \"spoofed email warning\" for emails that do not support sender domain authentication. This makes implementation an urgent priority for businesses distributing emails to individual consumers as well.<\/p>\n\n\n\n
[Reference] NTT Docomo, \u201cSpoofed Email Warning<\/a> <\/p>\n\n\n\nBack to Contents<\/a>\n\n\n\nHow Are Emails Sent? (The Basics)<\/h2>\n\n\n\n
To understand sender domain authentication, the first thing you should know is the difference between the \"Envelope From\" and the \"Header From.\" The mechanism of email is easier to understand when compared to the relationship between an envelope and the letter inside.<\/p>\n\n\n\n
The Sender on the Envelope (Envelope From)<\/h3>\n\n\n\n
This is the sender used for delivery purposes. In terms of physical mail, it is the name written on the envelope. It is not displayed on the recipient's email screen.<\/p>\n\n\n\n
The Sender on the Letter (Header From)<\/h3>\n\n\n\n
This is the sender displayed on the screen. The \"sender information\" we see on our email inbox screen refers to this.<\/p>\n\n\n\n
How Spoofers Exploit<\/h3>\n\n\n\n![\"\"](\"https:\/\/learningbox.online\/wp-content\/uploads\/blog\/en\/spoofing-protection-explanation-en.jpg\")
Basic Email Structure (Envelope From and Header From)<\/figcaption><\/figure>\n\n\n\nEven if the sender on the envelope and the sender on the letter are different, the email will still be delivered. It is also possible to change only the displayed name.<\/p>\n\n\n\n
For example, an email can be sent from a completely different location while spoofing the sender address to look like \"info@majorbank.co.jp\".
This is the technique used in email spoofing.<\/p>\n\n\n\n
The mechanisms designed to prevent this issue are SPF, DKIM, and DMARC. First, remember that \"there are two senders.\"<\/p>\n\n\n\nBack to Contents<\/a>\n\n\n\nWhat is SPF?<\/h2>\n\n\n\n
SPF is the first step in anti-spoofing measures. This is a mechanism where you register the servers authorized to send emails in your DNS. When Gmail receives an email, it verifies whether the sender is legitimate.
Let\u2019s first understand how this \"sender verification\" mechanism works.<\/p>\n\n\n\n
Basic Concept of SPF<\/h3>\n\n\n\n
SPF (Sender Policy Framework) is a mechanism for declaring in advance in the DNS \"which servers are allowed to send emails from this domain.\"<\/p>\n\n\n\n
For example, you pre-register information in the DNS such as, \"Emails from example.com are sent exclusively from the server with IP address 203.0.113.1 (*example for explanatory purposes).\"<\/p>\n\n\n\n
The receiving side checks whether the IP address of the server that actually transmitted the email is included in that registered list. If the email originates from an IP address not on the list, it can be identified as a \"potentially spoofed email.\"<\/p>\n\n\n\n
How SPF Works<\/h3>\n\n\n\n
The SPF verification flow is carried out through the following steps.<\/p>\n\n\n\n
\n- The sender transmits an email<\/li>\n\n\n\n
- The receiving server logs the IP address of the server from which the email arrived<\/li>\n\n\n\n
- The server queries the DNS for the domain in the Envelope From (e.g., example.com)<\/li>\n\n\n\n
- The server compares the SPF record in the DNS TXT record with the actual sending IP address<\/li>\n\n\n\n
- If they match, it is determined as \"SPF Pass\"; if they do not match, it is determined as \"Fail (Fail\/SoftFail)\"<\/li>\n<\/ol>\n\n\n\n
![\"\"](\"https:\/\/learningbox.online\/wp-content\/uploads\/blog\/en\/spoofing-protection-explanation-03-en.jpg\")
How SPF Works: The receiving server queries the DNS to match the IP address<\/figcaption><\/figure>\n\n\n\nHow to Read an SPF Record (Reference)<\/h3>\n\n\n\n
An actual SPF Record is written in the DNS TXT record as follows.<\/p>\n\n\n\n
\nv=spf1 include:spf.google.com ip4:203.0.113.1 ~all<\/p>\n<\/div>\n\n\n\n
Meaning of Each Element<\/h4>\n\n\n\n\n- v=spf1: Declaration of SPF Version 1<\/li>\n\n\n\n
- include:spf.google.com: Allows sending from Google's mail servers as well (when using external services like Gmail)<\/li>\n\n\n\n
- ip4:203.0.113.1: Allows sending from this IP address<\/li>\n\n\n\n
- ~all: Treats anything other than the above as \"SoftFail (warning)\" (-all indicates complete rejection)<\/li>\n<\/ul>\n\n\n\n
The difference between ~all and -all lies in the strictness of processing when SPF fails. While -all (HardFail) recommends complete rejection, legitimate emails may be misidentified as spam during forwarding, so in many cases, it is recommended to start with ~all to monitor the situation.<\/p>\n\n\n\n
The Limitations of SPF<\/h3>\n\n\n\n
Looking at this point, it might seem that setting up SPF alone can prevent spoofing.
However, SPF alone is insufficient. In fact, SPF has structural weaknesses that are fundamentally unavoidable.<\/p>\n\n\n\n
It Does Not Verify the Header From<\/h4>\n\n\n\n
What SPF verifies is the Envelope From (the sender on the envelope). It does not verify the Header From (the sender on the letter) displayed in email clients.<\/p>\n\n\n\n
In other words, spoofing that falsifies only the Header From while leaving the Envelope From set to a legitimate domain cannot be prevented by SPF alone.<\/p>\n\n\n\n
It Cannot Handle Email Forwarding<\/h4>\n\n\n\n
When an email is forwarded, the forwarding server's IP address becomes the new \"Sender IP.\" However, because the forwarding server's IP is not registered in the original SPF record, SPF authentication fails despite it being a legitimate email.<\/p>\n\n\n\n
To make up for these weaknesses, DKIM was introduced, which will be explained next.<\/p>\n\n\n\nBack to Contents<\/a>\n\n\n\nWhat Is DKIM? (Digital Signature for Tamper Prevention)<\/h2>\n\n\n\n
If SPF is a mechanism for verifying the sending server, the next necessary step is a mechanism to verify whether the email itself is authentic. This is where DKIM comes into play.<\/p>\n\n\n\n
A Basic Overview of DKIM<\/h3>\n\n\n\n
If SPF functions as an \"authorized server list,\" DKIM acts as an \"official seal of authenticity.\" The concept behind DKIM is much like affixing a corporate seal to a legal document.<\/p>\n\n\n\n
When the sender applies a \"digital signature\" to an email and the recipient verifies it, both parties can ensure that \"the message was generated by the authentic sender and remained unaltered in transit.\"<\/p>\n\n\n\n
How DKIM Works<\/h3>\n\n\n\n
DKIM attaches a digital signature directly to an email. Unlike SPF, which checks sender IP addresses, DKIM verifies whether the message originates from a legitimate sender (preventing spoofing) and whether the body content has been modified. Under the hood, DKIM relies on public-key cryptography.<\/p>\n\n\n\n
Sender-side processing follows these steps:<\/p>\n\n\n\n
\n- Calculate a hash value from the email's content (headers + body)<\/li>\n\n\n\n
- Encrypt the hash value using a private key to create a \"signature\"<\/li>\n\n\n\n
- Attach this signature to the email header as DKIM-Signature and transmit the message<\/li>\n<\/ol>\n\n\n\n
*A hash value is a fixed-length string produced from data via a one-way (irreversible) hash function that cannot be converted back to its original form.<\/p>\n\n\n\n
Receiver-side processing follows these steps:<\/p>\n\n\n\n
\n- Extract the signing domain (d=) and selector (s=) from the DKIM-Signature header<\/li>\n\n\n\n
- Query the DNS to retrieve the corresponding public key<\/li>\n\n\n\n
- Decrypt the signature using the public key to reveal the original hash value<\/li>\n\n\n\n
- Compare it against the newly computed hash value of the received email body<\/li>\n<\/ol>\n\n\n\n
*d= (signing domain) specifies the domain name taking responsibility for signing the email.
*s= (selector) acts as a unique identifier used to locate the correct public key, allowing a single domain to manage multiple keys.<\/p>\n\n\n\n![\"\"](\"https:\/\/learningbox.online\/wp-content\/uploads\/blog\/en\/spoofing-protection-explanation-04-en.jpg\")
How DKIM Works: Detecting message tampering through public-key digital signatures.<\/figcaption><\/figure>\n\n\n\nIf the hash values match, \"DKIM Authentication Passes,\" confirming the email was created by the real sender and left untouched.<\/p>\n\n\n\n
Inside the DKIM-Signature<\/h3>\n\n\n\n
The actual DKIM-Signature attached to an email header looks like this:<\/p>\n\n\n\n
\nDKIM-Signature: v=1; a=rsa-sha256; c=relaxed\/relaxed;
d=example.com; s=google; \u2026omitted\u2026
bh = hash value; b = signature data<\/p>\n<\/div>\n\n\n\n
Key Parameters:<\/h4>\n\n\n\n\n- d= (Domain): The signing domain, which plays a critical role during DMARC alignment checks.<\/li>\n\n\n\n
- s= (Selector): The key name used to query the public key in the DNS.<\/li>\n\n\n\n
- a = (Algorithm): The signature algorithm (rsa-sha256 is standard).\nWhat is a Selector?<\/li>\n<\/ul>\n\n\n\n
What Is a Selector?<\/h3>\n\n\n\n
A selector is an identifier that allows an organization to manage and rotate multiple DKIM key pairs under a single domain.<\/p>\n\n\n\n
For instance, given d=example.com and s=google, the receiving server fetches the public key from the DNS record google._domainkey.example.com.<\/p>\n\n\n\n
This architecture enables organizations using multiple email services to manage each integration with a distinct selector.<\/p>\n\n\n\n![\"\"](\"https:\/\/learningbox.online\/wp-content\/uploads\/blog\/en\/spoofing-protection-explanation-05-en.jpg\")
How to manage keys across multiple services<\/figcaption><\/figure>\n\n\n\nLimitations of DKIM<\/h3>\n\n\n\n
Configuring SPF and DKIM often creates a false sense of security that spoofing is completely solved. However, DKIM has clear limitations.<\/p>\n\n\n\n
Replay Attacks<\/h4>\n\n\n\n
DKIM cannot inherently prevent replay attacks, where a malicious actor intercepts an email containing a valid DKIM signature and resends it untouched to other recipients.<\/p>\n\n\n\n
Lack of Enforcement Policies<\/h4>\n\n\n\n
While DKIM determines whether an email is authentic, it offers no mechanism to define how receiving servers should handle messages when authentication fails. Handling failure scenarios is left to DMARC.<\/p>\n\n\n\n
DKIM verifies whether an email is authentic. However, it cannot dictate how to process failed emails. That responsibility belongs to DMARC, which is explained next.<\/p>\n\n\n\nBack to Contents<\/a>\n\n\n\nWhat Is DMARC?<\/h2>\n\n\n\n![\"\"](\"https:\/\/learningbox.online\/wp-content\/uploads\/blog\/spoofing-protection-explanation-06-1024x538.jpg\")
<\/figure>\n\n\n\nSPF and DKIM allow receiving servers to verify the sender's identity and detect email tampering. But how is an email handled when either check fails? DMARC makes that final decision.<\/p>\n\n\n\n
The Role of DMARC<\/h3>\n\n\n\n
DMARC (Domain-based Message Authentication, Reporting, and Conformance) receives authentication results from SPF and DKIM, serving as the central authority that dictates how failed emails are processed. DMARC fulfills three primary functions:<\/p>\n\n\n\n
Final Judgment<\/h4>\n\n\n\n
It evaluates an email's overall authenticity by combining SPF and DKIM authentication results with domain alignment (detailed below).<\/p>\n\n\n\n
Policy Declaration<\/h4>\n\n\n\n
It specifies how receiving mail servers should handle messages that fail authentication.<\/p>\n\n\n\n
Report Reception<\/h4>\n\n\n\n
It collects aggregate reports detailing who is sending emails using your domain.<\/p>\n\n\n\n
DMARC Policies<\/h3>\n\n\n\n
A DMARC record is a policy rule published in your DNS. It looks like this:<\/p>\n\n\n\n
\nv=DMARC1; p=none;<\/p>\n<\/div>\n\n\n\n
The \"p\" tag stands for \"policy\" and defines how receiving servers must handle messages that fail authentication.<\/p>\n\n\n\n
Three-Tier Policy<\/h4>\n\n\n\n
DMARC offers three enforcement levels:<\/p>\n\n\n\n
<\/figure>\n\n\n\nDamage caused by phishing scams is increasing year by year, leading to corporate financial losses, data breaches, and severe brand reputation damage. The technologies known as SPF, DKIM, and DMARC were specifically developed to counter these threats.<\/p>\n\n\n\n
-SPF (Sender Policy Framework)<\/b> is a mechanism that verifies whether the sending server is legitimate.
-DKIM (DomainKeys Identified Mail)<\/b> applies a digital signature to emails to confirm that they originate from a legitimate sender and that the content has not been tampered with.
-DMARC (Domain-based Message Authentication, Reporting, and Conformance)<\/b> is a policy mechanism that determines how receiving servers should handle emails that fail SPF or DKIM authentication.<\/p>\n\n\n\n
By configuring these technologies correctly, you can prevent email spoofing while simultaneously improving your overall delivery rates. Let\u2019s look at each mechanism in detail.<\/p>\n\n\n\n
Current State of Email Spoofing<\/h3>\n\n\n\n
In recent years, damages caused by \"spoofed emails\" impersonating actual companies or individuals have been surging rapidly. Cases exist where emails pretending to be from business partners infect systems with malware (a general term for software created with malicious intent), causing personal data leaks, or where emails instructing transfers to fake bank accounts result in financial theft.<\/p>\n\n\n\n
What makes spoofed emails so insidious is that the sender's From address can be freely altered from a technical standpoint. Attackers forge the domain of legitimate companies to send emails that appear completely unsuspect. It is extremely difficult for the human eye to distinguish them, which is precisely why damages continue unabated.<\/p>\n\n\n\n
Furthermore, spoofed emails directly lead to the risk of brand reputation damage. If your company's domain is exploited to send massive amounts of phishing emails, there is a risk of severely damaging the trust of recipients. Additionally, as a consequence of this impact, even legitimate emails may be sorted into spam folders, potentially disrupting critical communication with customers.<\/p>\n\n\n\n
Impact of the Gmail Email Sender Guidelines<\/h3>\n\n\n\n
In February 2024, Google tightened its \"Email Sender Guidelines.\" The outline of the guidelines is as follows:<\/p>\n\n\n\n
Required for all senders<\/h4>\n\n\n\n
Implementation of either SPF or DKIM<\/p>\n\n\n\n
Bulk senders of 5,000 or more emails per day<\/h4>\n\n\n\n
Implementation of all three: SPF, DKIM, and DMARC<\/p>\n\n\n\n
If left unaddressed, emails sent to Gmail users may fail to be delivered. Furthermore, in practice, DKIM is becoming a virtually mandatory requirement even for non-bulk senders. This is because emails lacking DKIM are heavily flagged by Gmail's spam filters.<\/p>\n\n\n\n
[Reference] Gmail, \u201cGuidelines for Email Senders<\/a> <\/p>\n\n\n\n Starting in January 2025, NTT Docomo began sequentially deploying \"spoofed email warning\" for emails that do not support sender domain authentication. This makes implementation an urgent priority for businesses distributing emails to individual consumers as well.<\/p>\n\n\n\n [Reference] NTT Docomo, \u201cSpoofed Email Warning<\/a> <\/p>\n\n\n\nBack to Contents<\/a>\n\n\n\n To understand sender domain authentication, the first thing you should know is the difference between the \"Envelope From\" and the \"Header From.\" The mechanism of email is easier to understand when compared to the relationship between an envelope and the letter inside.<\/p>\n\n\n\n This is the sender used for delivery purposes. In terms of physical mail, it is the name written on the envelope. It is not displayed on the recipient's email screen.<\/p>\n\n\n\n This is the sender displayed on the screen. The \"sender information\" we see on our email inbox screen refers to this.<\/p>\n\n\n\n Even if the sender on the envelope and the sender on the letter are different, the email will still be delivered. It is also possible to change only the displayed name.<\/p>\n\n\n\n For example, an email can be sent from a completely different location while spoofing the sender address to look like \"info@majorbank.co.jp\". The mechanisms designed to prevent this issue are SPF, DKIM, and DMARC. First, remember that \"there are two senders.\"<\/p>\n\n\n\nBack to Contents<\/a>\n\n\n\n SPF is the first step in anti-spoofing measures. This is a mechanism where you register the servers authorized to send emails in your DNS. When Gmail receives an email, it verifies whether the sender is legitimate. SPF (Sender Policy Framework) is a mechanism for declaring in advance in the DNS \"which servers are allowed to send emails from this domain.\"<\/p>\n\n\n\n For example, you pre-register information in the DNS such as, \"Emails from example.com are sent exclusively from the server with IP address 203.0.113.1 (*example for explanatory purposes).\"<\/p>\n\n\n\n The receiving side checks whether the IP address of the server that actually transmitted the email is included in that registered list. If the email originates from an IP address not on the list, it can be identified as a \"potentially spoofed email.\"<\/p>\n\n\n\n The SPF verification flow is carried out through the following steps.<\/p>\n\n\n\n An actual SPF Record is written in the DNS TXT record as follows.<\/p>\n\n\n\n v=spf1 include:spf.google.com ip4:203.0.113.1 ~all<\/p>\n<\/div>\n\n\n\n The difference between ~all and -all lies in the strictness of processing when SPF fails. While -all (HardFail) recommends complete rejection, legitimate emails may be misidentified as spam during forwarding, so in many cases, it is recommended to start with ~all to monitor the situation.<\/p>\n\n\n\n Looking at this point, it might seem that setting up SPF alone can prevent spoofing. What SPF verifies is the Envelope From (the sender on the envelope). It does not verify the Header From (the sender on the letter) displayed in email clients.<\/p>\n\n\n\n In other words, spoofing that falsifies only the Header From while leaving the Envelope From set to a legitimate domain cannot be prevented by SPF alone.<\/p>\n\n\n\n When an email is forwarded, the forwarding server's IP address becomes the new \"Sender IP.\" However, because the forwarding server's IP is not registered in the original SPF record, SPF authentication fails despite it being a legitimate email.<\/p>\n\n\n\n To make up for these weaknesses, DKIM was introduced, which will be explained next.<\/p>\n\n\n\nBack to Contents<\/a>\n\n\n\n If SPF is a mechanism for verifying the sending server, the next necessary step is a mechanism to verify whether the email itself is authentic. This is where DKIM comes into play.<\/p>\n\n\n\n If SPF functions as an \"authorized server list,\" DKIM acts as an \"official seal of authenticity.\" The concept behind DKIM is much like affixing a corporate seal to a legal document.<\/p>\n\n\n\n When the sender applies a \"digital signature\" to an email and the recipient verifies it, both parties can ensure that \"the message was generated by the authentic sender and remained unaltered in transit.\"<\/p>\n\n\n\n DKIM attaches a digital signature directly to an email. Unlike SPF, which checks sender IP addresses, DKIM verifies whether the message originates from a legitimate sender (preventing spoofing) and whether the body content has been modified. Under the hood, DKIM relies on public-key cryptography.<\/p>\n\n\n\n Sender-side processing follows these steps:<\/p>\n\n\n\n *A hash value is a fixed-length string produced from data via a one-way (irreversible) hash function that cannot be converted back to its original form.<\/p>\n\n\n\n Receiver-side processing follows these steps:<\/p>\n\n\n\n *d= (signing domain) specifies the domain name taking responsibility for signing the email. If the hash values match, \"DKIM Authentication Passes,\" confirming the email was created by the real sender and left untouched.<\/p>\n\n\n\n The actual DKIM-Signature attached to an email header looks like this:<\/p>\n\n\n\n DKIM-Signature: v=1; a=rsa-sha256; c=relaxed\/relaxed; A selector is an identifier that allows an organization to manage and rotate multiple DKIM key pairs under a single domain.<\/p>\n\n\n\n For instance, given d=example.com and s=google, the receiving server fetches the public key from the DNS record google._domainkey.example.com.<\/p>\n\n\n\n This architecture enables organizations using multiple email services to manage each integration with a distinct selector.<\/p>\n\n\n\n Configuring SPF and DKIM often creates a false sense of security that spoofing is completely solved. However, DKIM has clear limitations.<\/p>\n\n\n\n DKIM cannot inherently prevent replay attacks, where a malicious actor intercepts an email containing a valid DKIM signature and resends it untouched to other recipients.<\/p>\n\n\n\n While DKIM determines whether an email is authentic, it offers no mechanism to define how receiving servers should handle messages when authentication fails. Handling failure scenarios is left to DMARC.<\/p>\n\n\n\n DKIM verifies whether an email is authentic. However, it cannot dictate how to process failed emails. That responsibility belongs to DMARC, which is explained next.<\/p>\n\n\n\nBack to Contents<\/a>\n\n\n\n SPF and DKIM allow receiving servers to verify the sender's identity and detect email tampering. But how is an email handled when either check fails? DMARC makes that final decision.<\/p>\n\n\n\n DMARC (Domain-based Message Authentication, Reporting, and Conformance) receives authentication results from SPF and DKIM, serving as the central authority that dictates how failed emails are processed. DMARC fulfills three primary functions:<\/p>\n\n\n\n It evaluates an email's overall authenticity by combining SPF and DKIM authentication results with domain alignment (detailed below).<\/p>\n\n\n\n It specifies how receiving mail servers should handle messages that fail authentication.<\/p>\n\n\n\n It collects aggregate reports detailing who is sending emails using your domain.<\/p>\n\n\n\n A DMARC record is a policy rule published in your DNS. It looks like this:<\/p>\n\n\n\n v=DMARC1; p=none;<\/p>\n<\/div>\n\n\n\n The \"p\" tag stands for \"policy\" and defines how receiving servers must handle messages that fail authentication.<\/p>\n\n\n\n DMARC offers three enforcement levels:<\/p>\n\n\n\nNTT DOCOMO\u2019s \"Spoofed Email Warning\"<\/h3>\n\n\n\n
How Are Emails Sent? (The Basics)<\/h2>\n\n\n\n
The Sender on the Envelope (Envelope From)<\/h3>\n\n\n\n
The Sender on the Letter (Header From)<\/h3>\n\n\n\n
How Spoofers Exploit<\/h3>\n\n\n\n
This is the technique used in email spoofing.<\/p>\n\n\n\nWhat is SPF?<\/h2>\n\n\n\n
Let\u2019s first understand how this \"sender verification\" mechanism works.<\/p>\n\n\n\nBasic Concept of SPF<\/h3>\n\n\n\n
How SPF Works<\/h3>\n\n\n\n
\n
How to Read an SPF Record (Reference)<\/h3>\n\n\n\n
Meaning of Each Element<\/h4>\n\n\n\n
\n
The Limitations of SPF<\/h3>\n\n\n\n
However, SPF alone is insufficient. In fact, SPF has structural weaknesses that are fundamentally unavoidable.<\/p>\n\n\n\nIt Does Not Verify the Header From<\/h4>\n\n\n\n
It Cannot Handle Email Forwarding<\/h4>\n\n\n\n
What Is DKIM? (Digital Signature for Tamper Prevention)<\/h2>\n\n\n\n
A Basic Overview of DKIM<\/h3>\n\n\n\n
How DKIM Works<\/h3>\n\n\n\n
\n
\n
*s= (selector) acts as a unique identifier used to locate the correct public key, allowing a single domain to manage multiple keys.<\/p>\n\n\n\nInside the DKIM-Signature<\/h3>\n\n\n\n
d=example.com; s=google; \u2026omitted\u2026
bh = hash value; b = signature data<\/p>\n<\/div>\n\n\n\nKey Parameters:<\/h4>\n\n\n\n
\n
What Is a Selector?<\/h3>\n\n\n\n
Limitations of DKIM<\/h3>\n\n\n\n
Replay Attacks<\/h4>\n\n\n\n
Lack of Enforcement Policies<\/h4>\n\n\n\n
What Is DMARC?<\/h2>\n\n\n\n
<\/figure>\n\n\n\nThe Role of DMARC<\/h3>\n\n\n\n
Final Judgment<\/h4>\n\n\n\n
Policy Declaration<\/h4>\n\n\n\n
Report Reception<\/h4>\n\n\n\n
DMARC Policies<\/h3>\n\n\n\n
Three-Tier Policy<\/h4>\n\n\n\n
![\"\"](\"https:\/\/learningbox.online\/wp-content\/uploads\/blog\/spoofing-protection-explanation-07-1024x538.jpg\")
<\/figure>\n\n\n\n![\"\"](\"https:\/\/learningbox.online\/wp-content\/uploads\/blog\/en\/spoofing-protection-explanation-08-en.jpg\")
![\"\"](\"https:\/\/learningbox.online\/wp-content\/uploads\/blog\/spoofing-protection-explanation-09-1024x538.jpg\")
<\/figure>\n\n\n\n![\"thumbnail](\"https:\/\/learningbox.online\/wp-content\/uploads\/blog\/en\/en_information_leak_9_measures_00.jpg\")
\n <\/div> \n