Google And Yahoo 2024 Email DMARC Requirements

If your emails have started bouncing in February 2024 and you have no idea why, this could well be the reason. Back in October 2023, with very little fanfare, Google announced new requirements for email authentication. A vast majority of email systems already used the validation tools provided by most email systems. 

For bulk senders, however, meaning if you have ever sent more than 5000 emails in one day, Google increased the sender requirements somewhat. However, not everyone realized that Google will start rejecting email traffic that doesn’t meet the new sender requirements as early as February 2024. Read on for the details.

Why is this happening?

Spam has been a problem since email adoption went beyond the lab to consumers at large. We have been fighting it ever since in an ever-escalating arms race of blacklists, filtering and verification. Filters try to recognize spam, spammers try to find new ways to get past the filters. This latest change is just another escalation in this arms race.

In this latest change, the focus is on emails coming from the server of record, making sure they originate on that server, letting people stop receiving emails and making sure that senders monitor that their emails are compliant.

Additional Google and Yahoo Email Requirements for 2024

As of February 2024, for all email senders, messages sent must have SPF and DKIM alignment, and the sender must maintain a spam rate of 0.3% at the most, ideally targeting 0.1%, or one in 1000 emails being marked as spam. Clearly you don’t want the recipient to ever mark a message as spam.

For bulk senders (more than 5000 email sent in one day, ever), in addition to the previous requirements, they must also have a DMARC policy in place, the messages must pass DMARC alignment, and include a one-click unsubscribe (as opposed to a link to another page where more buttons must be pressed or an email address typed in to unsubscribe). The DMARC requirement caught a lot of companies by surprised because it has long been an optional email security feature. Combined with some complexity and the potential for emails being blocked by Gmail and Yahoo, this has meant that many companies never even set up dmarc, and don’t meet sender requirements on google’s new policies.

SPF, DKIM, DMARC, and alignment – What does this all mean?

 

SPF Explanation (Sender Policy Framework)

Sender Policy Framework (SPF) is like a guest list for an email party hosted by your domain (your website’s address on the internet). Just as you’d have a list at the door to check if guests are invited, SPF is a list that checks if the computer sending an email is allowed to send it on behalf of your domain.

When someone sends an email, the receiving email server (the “bouncer” checking the list at the email party) looks up the SPF record, which is a special note left in the internet’s address book (DNS) that says which computers (IP addresses) are allowed to send emails for your domain.

If the computer sending the email is on the list, the email is let in smoothly, just like a guest on the list at a party. If it’s not on the list, the email might be turned away or marked with a warning, like a party crasher who wasn’t invited. This helps prevent imposters from sending emails pretending to be you, keeping your email reputation safe and reducing spam.

DKIM Explanation (DomainKeys Identified Mail)

Imagine sending a sealed letter with a unique wax seal (your domain’s signature) that only you have. DKIM (DomainKeys Identified Mail) is like this wax seal for your emails. When you send an email, DKIM adds a special digital “seal” to it. This seal is created based on the content of your email and is unique to your domain (like your website’s address).

Before your email arrives at its destination, it travels through the internet, possibly stopping at various “post offices” (email servers). The unique seal helps ensure that your message isn’t opened or changed along the way. When the email arrives, the receiving server checks the seal by comparing it to a public “key” (like a seal pattern) that you’ve left in a public directory (DNS) for anyone to find.

If the seal matches the pattern you’ve provided, it means the email really is from you and hasn’t been tampered with. If the seal doesn’t match, it could mean someone tried to change the email or pretend it was from you. DKIM helps keep your emails safe and increases the chances they’ll be delivered properly, reducing the risk of them being mistaken for spam or malicious emails.

DMARC Explanation (Domain-based Message Authentication, Reporting, and Conformance)

DMARC is a set of rules and a reporting system for your mailman (the email system). It’s like putting instructions on your mailbox that tell the mailman what to do if they find a letter that looks suspicious (like it’s not really from who it says it’s from) or doesn’t have the proper postage (authentication like SPF and DKIM).

With DMARC, you can tell the mailman (email servers) to do one of three things with suspicious mail: return to sender (reject the email), put it in a special box for you to check later (quarantine or spam folder), or just deliver it as usual but let you know it looked a bit odd (no action, but report back).

The reporting part of DMARC is like getting a summary of all the mail that came to your house, which ones looked suspicious, and what the mailman did with them based on your instructions. This helps you keep an eye on who’s sending mail that looks like it’s from you and catch any potential imposters trying to trick your friends, family, or customers with fake emails. It’s a way to make sure that the emails from your domain are trusted and that any fakes are dealt with according to your wishes.

Feel free to reach out to us if you have questions about DMARC report monitoring.

Implement Email Server Authorization: SPF for Google and Yahoo

In technical terms, SPF is designed to detect and prevent email spoofing by providing a mechanism for mail exchangers to verify that incoming mail from a domain is being sent from a host authorized by that domain’s administrators. It is defined in RFC 7208.

An SPF record is published in the Domain Name System (DNS) as a TXT record. The record specifies which IP addresses and/or servers are permitted to send email on behalf of the domain. When an inbound mail server receives an email, it can check the SPF record of the sender’s domain to verify that the email is coming from a designated IP address or server. This check is done by looking up the domain’s SPF record in DNS and comparing the sending mail server’s IP address against the IP addresses listed in the SPF record.

If the sending server’s IP matches one of the authorized IPs in the SPF record, the email can be considered legitimate with respect to the domain’s sending policy. If there’s no match, the email could be marked as spam or rejected based on the receiving server’s policies for handling SPF failures.

SPF allows domain owners to specify their mail sending policy, which includes mechanisms for defining allowed hosts, includes from other domains, IP address ranges, and how strictly the receiving server should enforce the policy (e.g., “fail”, “softfail”, “neutral”, “pass”).

So how do you build your SPF DNS record?

SPF record format

Version Tag: Every SPF record starts with a version tag. For SPF, this is always “v=spf1”. This tag indicates that the DNS TXT record is an SPF record and uses SPF version 1 syntax.

IP Addresses:

• ip4: Specifies an allowed IPv4 address or range that can send emails for the domain. For example, ip4:192.168.0.1 allows a specific IP address, whereas ip4:192.168.0.0/24 allows a range of IP addresses from 192.168.0.0 to 192.168.0.255.
• ip6: Similar to ip4 but for IPv6 addresses. An example is ip6:fd03:12f2::/48.

Mechanisms: These define the rules for which sending servers are allowed or not. Common mechanisms include:

• a: Allows the domain’s A records to send emails. Optionally, a domain can be specified (e.g., a:example.com) to allow the A record of that domain.
• mx: Allows the domain’s MX records to send emails. Like a, it can be qualified with a specific domain (e.g., mx:example.com).
• include: Incorporates the SPF policy of another domain. This is useful for services like email marketing platforms (e.g., include:_spf.google.com for Google Workspace).

Modifiers:

• redirect: Redirects the SPF evaluation to another domain’s SPF record. This is different from include in that it replaces the entire check with the target domain’s SPF policy.
• exp: Defines an explanation string that can be returned to senders when mail is rejected due to the SPF policy.

Qualifiers:

• + (Pass): The default qualifier if none is specified. Indicates that the sending server is allowed to send mail.
• - (Fail): Indicates that the sending server is not allowed to send mail, leading to rejection of the message.
• ~ (Softfail): Suggests that the sending server is probably not authorized, but the email should not be outright rejected (often treated as suspicious).
• ? (Neutral): Indicates that the domain makes no assertion about the legitimacy of the sending server.

A sample SPF record might look like this:

v=spf1 ip4:192.168.0.1 include:_spf.google.com ~all

This record starts with the version tag (v=spf1), specifies an IPv4 address (ip4:192.168.0.1) that’s allowed to send email, includes the SPF policy of Google (include:_spf.google.com), and ends with ~all indicating that emails from IPs not previously listed should be treated with suspicion but not automatically rejected (softfail).

Implement Email Authentication: DKIM for Google and Yahoo

The DKIM security standard is designed to ensure that messages are not altered in transit between sending and receiving servers. It provides a method for validating a domain name identity that is associated with a message through cryptographic authentication.

DKIM works by allowing the sending mail server to attach a digital signature to outgoing emails. This signature is generated by applying a private key to the email’s header and body, and the resulting signature is then included in the email’s headers. The corresponding public key is published in the Domain Name System (DNS) as a TXT record under the sending domain.

When a receiving mail server gets an email, it retrieves the DKIM signature from the email’s headers and then looks up the sender’s public DKIM key in DNS. Using this public key, the receiving server can decrypt the signature to verify that the message was indeed signed by the private key of the sending domain and that it has not been tampered with in transit. Successful DKIM verification can be a positive signal towards the legitimacy of an email, aiding in its delivery to the recipient’s inbox and not spam.

DKIM setup involves generating a key pair (private and public keys), configuring the sending mail server to sign outgoing emails with the private key, and publishing the public key in the domain’s DNS. DKIM records can include several fields such as the version, key type, public key, and others that help in the verification process.

DKIM record format

Version (v): This indicates the DKIM version being used, typically set to “DKIM1” (v=DKIM1). It’s the first tag in a DKIM record and specifies that this DNS record is a DKIM record.

Public Key (p): The actual public key used to verify the DKIM signature. The sending server signs the email with a corresponding private key, and the receiving server uses this public key to verify that signature.

Key Type (k): This field specifies the cryptographic algorithm used to generate the signature. Common values are “rsa” for RSA keys, which is the most widely used.

Domain (d): Specifies the domain of the signing entity. This is used to confirm that the email is indeed from the domain it claims to be from.

Selector (s): A DKIM selector is an arbitrary string used to differentiate between multiple DKIM keys under the same domain. This allows a domain to have multiple DKIM keys published in DNS simultaneously. The selector is specified in the email header and is used to locate the correct DKIM record in DNS.

Flags (t): Optional flags that can provide additional information about the key and its usage. For example, a “y” flag indicates that this key is still being tested, and an “s” flag indicates that the key is only used for email originating from the same domain (strict mode).

Service Type (s): This optional tag specifies the services that the key can be used for, with “email” being a common value, indicating that the DKIM record is used for email authentication.

Notes (n): An optional field for including notes from the administrator. This is not used in the verification process but can be used to provide additional information about the DKIM record.

A sample DKIM record might look something like this:

v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC4nE3U…;

This example starts with the version (v=DKIM1), specifies the key type as RSA (k=rsa), and includes the public key (p=MIGfMA0G...). The ellipsis (…) indicates that the public key is much longer in reality. This record doesn’t include all possible tags, as many are optional and depend on the specific requirements and configurations of the sending domain.

Implement Email Monitoring: DMARC for Google and Yahoo

DMARC builds upon the SPF and DKIM protocols to enhance the security and authenticity of email communications. DMARC enables domain owners to publish policies in their DNS records that dictate how receiving mail servers should handle emails that don’t pass SPF and DKIM checks.

A DMARC policy allows domain owners to specify what should happen to emails that fail authentication checks: they can be rejected, quarantined (typically sent to the spam folder), or have no action taken, with the policy applied at the discretion of the receiving email server. This policy helps protect the domain from unauthorized use, such as phishing and email spoofing.

DMARC also includes a reporting feature, where receiving email servers can send reports back to the domain owner about emails they’re seeing: which passed or failed SPF and DKIM checks, and what action was taken based on the domain’s DMARC policy. These reports are crucial for domain owners to understand and improve their email authentication setup and to identify potential authentication issues or abuse.

To implement DMARC, a domain owner publishes a DMARC record in their DNS. This record specifies the policy for handling failed messages and an email address to send aggregate and forensic reports to. The DMARC record uses a specific syntax to outline the domain’s policy and preferences for report handling.

Without monitoring, DMARC can cause more problems than it solves, this is why so many companies have put it off. Now that it becomes a required part of the email ecosystem for the large email providers like Google and Yahoo, everyone is scrambling to make sure their emails are compliant and won’t end up rejected. Monitoring means that somewhere a system or a technical person is looking at the returned reports and acting as necessary to adjust settings or whitelist new servers to keep everything running smoothly.

DMARC Record Format

Version (v): This is always the first tag in a DMARC record and specifies the DMARC version. For current DMARC records, this is set to “DMARC1” (v=DMARC1).

Policy (p): This tag defines the policy to be applied by email receivers when SPF and/or DKIM checks fail. The policy can be:

• none: Treat the mail the same as if no DMARC policy were in place (monitoring mode).
• quarantine: Treat the mail suspiciously, which usually means placing it in the spam folder.
• reject: Reject the mail outright, preventing it from being delivered to the recipient’s mailbox.

Subdomain Policy (sp): This optional tag specifies the policy for subdomains and can differ from the main domain policy. If not specified, subdomains will inherit the domain’s policy.

Percentage (pct): This optional tag specifies the percentage of messages to which the DMARC policy is applied. This allows domain owners to gradually implement DMARC by starting with a smaller percentage of messages.

Reporting Interval (ri): This optional tag indicates how often email receivers should send aggregate reports (in seconds). The default is 86400 seconds (24 hours) if not specified.

Aggregate Report URIs (rua): Specifies an email or URI to which aggregate reports of DMARC failures should be sent. These reports provide an overview of the volume and sources of messages failing DMARC checks.

Forensic Report URIs (ruf): Specifies an email or URI to which forensic reports of individual DMARC failures should be sent. These reports provide detailed information about individual failure instances, useful for in-depth analysis.

Failure Reporting Options (fo): This optional tag specifies the conditions under which forensic reports should be generated. Common values include:

• 0: Generate a report if all authentication methods (SPF and DKIM) fail.
• 1: Generate a report if any authentication method fails.
  • d: Generate a DKIM failure report.
  • s: Generate an SPF failure report.

Alignment Mode for DKIM (adkim): This optional tag specifies the DKIM identifier alignment mode, which can be:

• r for relaxed alignment: The Organizational Domain part of the DKIM domain (d= tag in the DKIM signature) must match the Organizational Domain of the From: address.
• s for strict alignment: The DKIM domain must exactly match the From: address domain.

Alignment Mode for SPF (aspf): Similar to adkim, this tag specifies the SPF identifier alignment mode, with the same r (relaxed) and s (strict) options.

A sample DMARC record might look like this:

v=DMARC1; p=quarantine; sp=none; pct=100; rua=mailto:dmarc-reports@example.com; ruf=mailto:dmarc-failures@example.com; adkim=r; aspf=r;

In this example, the policy is set to quarantine messages that fail DMARC checks, with no specific policy for subdomains (sp=none), applying the policy to 100% of messages (pct=100). It specifies where to send aggregate reports (rua) and forensic reports (ruf), and uses relaxed alignment for both DKIM and SPF (adkim=r; aspf=r).

Next Steps

In this article we have tried to provide all the technical information needed to comply with the new guidelines and technical requirements that Yahoo and Gmail requires starting right now. We have also tried to explain the issue in less technical jargon, though technical terms are an unavoidable part of the email authentication protocol. If you are just starting your DMARC journey, we understand it can be a little daunting. If you need assistance to deploy dmarc for your organization, better understand dmarc protocol or ask about monitoring, contact us. We can help.