Understanding the "Authenticate Their Email" Requirement - Google & Yahoo Initiative

Understanding Google and Yahoo Sender Requirements Authenticate their email
1

In light of the recent standards set by Google and Yahoo for bulk email senders, our first discussion in this series focuses on the “Authenticate Their Email” requirement. This is a crucial step towards enhancing email security and deliverability.

Why Email Authentication?

Google and Yahoo are mandating strong email authentication to protect both email recipients and senders. Proper authentication helps in combating email spoofing and phishing, ensuring the sender’s legitimacy.

Key Authentication Steps for Compliance:

Set Up DMARC: Implement a DMARC policy in your DNS. Begin with a monitor-mode policy (p=none) to track and understand your email sources. Utilize dmarcian’s free DMARC Record Wizard or the DMARC Inspector for initial setup and monitoring.

Utilize SPF and DKIM:

  • SPF (Sender Policy Framework): Create an SPF record that lists all authorized email senders for your domain. This helps in preventing spammers from using your domain to send unauthorized emails.
    • When setting up your SPF record, it’s important to list only the authorized email senders that use your domain in the “Return-Path.” Avoid overpopulating your SPF record based on general recommendations, especially from third-party providers who often send emails from their own domains.
    • To accurately determine which senders should be included in your SPF record, review your DMARC data. This data clearly shows which domain an email provider uses for SPF, helping you make informed decisions about your SPF record entries.
  • DKIM (DomainKeys Identified Mail): Enable DKIM for your domain to allow receiving servers to verify that you, the domain owner, actually sent the message. Google specifically requires a DKIM key of 1024 bits or longer, with a 2048-bit key recommended.

Ensure Alignment in DMARC:

  • Your emails must pass DMARC, which can be achieved through SPF or DKIM alignment.
  • For DKIM, ensure the ‘d=’ value in the email header matches your ‘From:’ domain.
  • For SPF, the ‘Return-Path’ should align with your sending domain.

PTR Records for Sending IPs: Verify that each IP address used for sending emails has a corresponding PTR record in DNS, linking the IP address and the sending hostname.This is known as a Forward-confirmed reverse DNS (FCrDNS) lookup. This step is managed by the domain and email administrators of your organization.

  • A PTR record, short for Pointer record, is a type of Domain Name System (DNS) record that maps an IP address to a domain name, effectively the reverse of an A or AAAA record. While A and AAAA records translate domain names to IP addresses, a PTR record does the opposite – it provides a way to associate an IP address with a domain name.
  • A FCrDNS check involves 3 steps performed by the receiver.
    • Reverse DNS Lookup: When an email server receives a message, it performs a reverse DNS lookup to find the domain name associated with the IP address from which the email originated.
    • Forward DNS Lookup: After finding the domain name from the PTR record, the server then does a forward DNS lookup on that domain name.
    • Verification: The email is considered authentic if the forward DNS lookup returns the same IP address as the original sending IP. This process confirms that the IP address and domain name are legitimately paired, adding a layer of trust.
  • Most third-party services and email security providers, like Microsoft 365, already use IPs with correctly configured PTR records that pass Forward-Confirmed Reverse DNS (FCrDNS) checks. No action is needed for these. PTR record setup is mainly required for devices and servers that send emails using IPs directly assigned to customers by their ISPs.

Why It Matters:

Authenticated emails are less likely to be rejected or marked as spam, thereby protecting your organization’s reputation and improving email deliverability.

Next Steps and dmarcian’s Support:

Monitor your DMARC setup using visualization tools and adjust your sending practices as needed. Our platform provides comprehensive tools and support to navigate this authentication process.

Further Information:

Understanding the Gmail and Yahoo DMARC Requirements [dmarcian.com]
Yahoo Announcement
Google Announcement

1 Like
2

Hi,

I have 2 questions about PTR reqirement part.

  1. Does the PTR have to be related to email header address domain?
    For example many of my customers use ESP in which PTR is their domain, such as fc8025-h.cuenote.jp where cuenote.jp is the domain of ESP. Is this OK?

  2. If the PTR requrement fails but DKIM is good with correct alignment, is it OK? Or does Google still thinks not good enough?

3

Hi Masahiro,

Great questions.

  1. No, it doesn’t have to be related. The PTR requirement is that it exists. It can be of any domains. This is very common due to cloud hosting of many email service providers where a branded PTR is not possible, such as Microsoft 365 where all PTRs are *.outlook.com.

The important requirements surrounding a PTR is that it passes the Forward-confirmed reverse DNS lookup (FCrDNS). As put by Google “Your sending IP address must have a PTR record. PTR records verify that the sending hostname is associated with the sending IP address. Every IP address must map to a hostname in the PTR record. The hostname specified in the PTR record must have a forward DNS that refers to the sending IP address.”

Meaning, let’s assume you have an on premise server with a NAT to a public IP from your ISP of 192.0.2.10. This is the IP the world sees when you send email. Your set your server hostname to mail.example.com. Successful FCrDNS means that a DNS “A” query for mail.example.com must return 192.0.2.10, and a reverse lookup of 192.0.2.10 must return mail.example.com.

  1. It is not. The two are not in an “OR” relationship as far as requirements go. Google requires that DMARC pass AND that PTR be properly configured to pass a FCrDNS check.

I hope this helps!

1 Like
4

Hi Asher,

Thank you so much for your consice answer!
I read Dmarcian Blog about FCrDNS, but I couldn’t understand. Now I do.

5

Hi Asher,

I have 1 more question regarding the PTR requirement.
Google’s Email sender guidelines in secion " Infrastructure configuration" says following.;

IP addresses

Your sending IP address must have a PTR record. PTR records verify that the sending hostname is associated with the sending IP address. Every IP address must map to a hostname in the PTR record. The hostname specified in the PTR record must have a forward DNS that refers to the sending IP address.

Set up valid reverse DNS records of your sending server IP addresses that point to your domain. Check for a PTR record with the Google Admin Toolbox Dig tool.

Important: The sending IP address must match the IP address of the hostname specified in the Pointer (PTR) record.

This means PTR domain should be same as SMTP helo domain for email senders with over 5000/day volume?

I justed tested this by using my Linux VM, configuring postfix smtp_helo_hostname and PTR to be different. And sent several emails to my Gmail from there. Gmail accepted as normal email. So at lease it’s OK with low volume senders. Is this different for high volume senders?
Please let me know if you know this.

Thanks!

6

Correct, the PTR record will generally be the same as the EHLO domain, which permits the forward confirmed reverse DNS to pass, and meet the Google/Yahoo authentication sender requirements. This is general best practice, followed by most large email service providers and is already configured without a need, or even the possible to change it.

This becomes more important when you have systems under your control where the PTR and hostnames fall within management of your ISP and DNS zone.

This validation is a requirement for all senders, not just bulk senders.

1 Like
7

I see. Thanks for the clarificaiton!