If I send an email to a Gmail account using my email address, how does Gmail know it’s definitely from me and not a hacker?

SPF

SPF (Sender Policy Framework) allows the publication of authorized mail servers for a domain, helping to prevent sender address forgery. Here’s an example of how it works:

1. SPF Record Retrieval: The receiving email server retrieves the SPF record from the DNS records for the domain 73007300.xyz.
2. Verification: The receiving server checks the SPF record to verify all the IP addresses authorized to send emails on behalf of the domain.
3. Trusted Email: If the SPF check passes, the receiving server considers the email trusted. It proceeds with processing the message, confident that it was sent from an approved sending server.
4. Illegitimate Email: If the SPF check fails, the message is deemed illegitimate and is handled according to the receiving server’s failure process.

I set an SPF record in my DNS records:

This tells Gmail that when it receives an email from my address, if the email originates from 51.79.156.122/24 or 51.79.216.166/24, it is from my domain.

we can also use DnsChecker to verify SPF record.

For rest part, I will use the DnsChecker to demonstrate.

when we open gmail, check the email I sent:

Gmail did check the SPF record.

But how does Gmail know the email content hasn’t been tampered with?

DKIM

DKIM (DomainKeys Identified Mail)

DKIM adds a digital signature to emails, ensuring that the content has not been tampered with in transit.

To use DKIM, the email server is configured to attach DKIM signatures when sending emails. These signatures travel with the emails and are verified by the receiving servers, helping them reach their final destination.

These signatures work like a watermark:

• An email provider generates both public and private keys.
• The public key is provided to the domain owner, who places it in the publicly available domain DNS record as the DKIM record.
• The sending email server signs an email with the private key, creating a “digital signature.” This signature is added as an extra header to assist the receiving servers in verification.
• The receiving email server locates the domain’s DKIM record, fetches the public key, and uses it to verify the digital signature.
• The receiving server can then confirm that the email was sent from the specified domain and remains unaltered during its transit.

When Gmail receives an email from my domain, it will extract the selector (which is x) and the domain (which is 73007300.xyz) from the email header. The public key can then be retrieved from my DNS record at x._domainkey.73007300.xyz, where _domainkey is fixed.

check on DNSCheck

Then Gmail can decrypt the hash using my public key, compute a hash of the same fields, and compare it to the decrypted hash.

But how can I know whether the target user received my email? Can the target server provide me with some feedback?

DMARC

DMARC (Domain-based Message Authentication, Reporting, and Conformance) builds on SPF and DKIM, providing additional instructions on how receivers should handle emails that fail authentication tests. It also generates reports that help senders improve their email protection practices.

DMARC is a protocol that enhances email authentication by working alongside SPF and DKIM to protect your domain from abusive activity, such as spoofing by hackers and other attackers. It provides you with the ability to monitor and control your domain’s email authentication policies. By ensuring that phishing emails and malware cannot be sent from your domain, DMARC strengthens your email security posture.

DMARC supplements SMTP (Simple Mail Transfer Protocol) by defining policies for email authentication, which SMTP does not include on its own.

Example of a DMARC record:

• RUA (Aggregate Reports) are primarily used for monitoring and gaining insights into the overall email authentication health of a domain.
• RUF (Forensic Reports) are useful for detailed, case-by-case investigation of DMARC failures but can generate large volumes of data and may raise privacy concerns due to the detailed nature of the reports.
• The ‘p=quarantine’ policy aims to mitigate the risk of fraudulent or spoofed emails being delivered to recipients by instructing receiving servers to place suspicious emails into a special area (like a spam or junk folder) rather than delivering them directly to the inbox. This option can be set to None, Quarantine, or Reject.

DMARC allows us to receive reports on your domain’s sending activity. With support from ISPs (Gmail, Yahoo, Microsoft, and more), these reports are sent to specified email addresses containing all of the domain’s messages.

However, you may have noticed that even when SPF and DKIM pass, my emails sent to Gmail are still marked as spam, meaning they are unwanted. How can this be avoided?

Return-path

According to Twilio SendGrid, the Return-path is essential for mass email campaigns as it effectively manages bounced emails. When sending emails to large lists, numerous messages may bounce, cluttering the original sending inbox. A designated return-path directs these bounce messages to a separate inbox, keeping the sending inbox clear. Additionally, the return-path enhances email deliverability and sender reputation by validating the sender’s identity. As an SMTP address, it helps servers and inbox providers determine how to filter messages, thereby boosting the sender’s credibility and reputation.

This time, I will use Postmark to send emails, which can enhance my credibility.

After config proper DNS record:

Now I can use Postmark to send Email:

This time, email sending from my domain to Gmail was not marked as Spam:

Because I configured a DNS record with Postmark to handle my email sending, as outlined in the Postmark documentation, Postmark helps deliver and track application emails. This capability enhances my credibility with Gmail.