How to Prevent Domain and Email Spoofing

Important: Starting February 2024, Gmail will require the following for senders who send 5,000 or more messages a day to Gmail accounts: Authenticate outgoing email, avoid sending unwanted or unsolicited email, and make it easy for recipients to unsubscribe. Learn more about requirements for sending 5,000 or more emails per day.

Domain spoofing – also known as email spoofing or impersonation, is a fraudulent activity that involves the use of fake or forged email addresses to deceive recipients into thinking that a message comes from a legitimate source. It is a common tactic used by cybercriminals to trick users into sharing sensitive information or clicking on malicious links.

To prevent domain spoofing, here are some best practices to follow:

1. Implement email authentication protocols: Two email authentication protocols that are commonly used to prevent domain spoofing are Sender Policy Framework (SPF) and Domain-based Message Authentication, Reporting, and Conformance (DMARC). SPF allows the receiving mail server to verify that the IP address sending the email is authorized to send on behalf of the domain. DMARC adds an extra layer of protection by allowing the domain owner to specify what actions to take on messages that fail SPF or DKIM checks.
2. Monitor your domain: Regularly monitor your domain for unauthorized changes, such as changes to DNS settings or MX records. Any unauthorized changes could be a sign of a domain hijacking attempt.

Google Workspace MX records

If your mailbox that you use to receive email replies is managed by Google Workspace (formerly Gsuite) you need to add five MX records for redundancy and to ensure reliable email delivery. MX records are used by email servers to determine where to deliver email messages for a particular domain.

Google Workspace distributes its MX records across five different priority levels (from 1 to 5) and points them to different servers. This provides redundancy and helps ensure that email is always delivered to a Google server, even if one or more of the servers are temporarily unavailable.

By using multiple MX records with different priority levels, Google Workspace can handle high volumes of email traffic and provide reliable email service to its users. This approach also helps prevent email downtime or delays, which is critical for businesses that rely heavily on email communication.

Why using 5 MX records is important?

Using five MX (Mail Exchange) records instead of just one offers important advantages for email reliability and ensures uninterrupted mail delivery. While Google may suggest one MX record for simplicity, it’s essential to consider the potential drawbacks.

Firstly, having five MX records provides redundancy in case one of the mail servers encounters issues or downtime. Email servers can occasionally experience temporary problems, and having multiple MX records means that if one server fails, incoming emails can still be routed to the remaining servers, ensuring uninterrupted mail delivery.

Secondly, having multiple MX records can improve email load distribution and enhance performance. When you use five MX records, the email traffic gets distributed among multiple servers, preventing any single server from becoming overwhelmed during periods of high email volume. This can result in faster email delivery and a more efficient email system.

In summary, using five MX records is a proactive approach to safeguard against email delivery interruptions and maintain the reliability of your email system. It ensures that your organization can consistently send and receive emails, even in the face of server issues or traffic spikes.

Learn More: Google Workspace MX record values

Google Workspace SPF records

A Sender Policy Framework (SPF) record is a DNS record that identifies which mail servers are authorized to send email on behalf of a particular domain. In Google Workspace, an SPF record is used to verify that emails sent from a domain are legitimate and not forged or spoofed.

To set up an SPF record for Google Workspace, you need to add a TXT record to your domain’s DNS settings: Add your SPF record at your domain provider

SPF mechanisms and qualifiers

The SPF DNS record is a TXT record that is added to the DNS configuration of a domain. The record consists of a series of mechanisms and qualifiers. Here’s a basic structure of an SPF record:

v=spf1 <mechanism>:<qualifier> <mechanism>:<qualifier> …

Let’s break down the components:

v=spf1: This indicates the SPF version. It must always be the first element of the SPF record.

Mechanisms: These specify the allowed sending mechanisms. Common mechanisms include:

• a: Allows the specified domain’s A record.
• mx: Allows the specified domain’s MX (mail exchange) records.
• include: Specifies another domain whose SPF records should be included.
• ip4 and ip6: Specifies an IPv4 or IPv6 address allowed to send mail.
• all: Represents the default rule, which can be used to specify the default action if no other mechanisms match.

Qualifiers: These indicate the action to take if a mechanism fails. Common qualifiers include:

• + (Pass): The client is authorized.
• – (Fail): The client is not authorized.
• ~ (SoftFail): The client is not authorized, but the server may still accept the message.
• ? (Neutral): The client is neither authorized nor unauthorized.

Here’s an example SPF record:

v=spf1 a mx ip4:192.168.1.1 include:_spf.example.com ~all

In this example:

• a: Allows the domain’s A record.
• mx: Allows the domain’s MX records.
• ip4:192.168.1.1: Allows the specified IPv4 address.
• include:_spf.example.com: Includes the SPF records of _spf.example.com.
• ~all: Specifies a soft fail, meaning that if the email doesn’t match any of the previous mechanisms, it will be accepted, but marked as potentially suspicious.
  It’s important to note that the SPF standard supports additional modifiers, such as redirect and exp, for more advanced configurations. Always remember to thoroughly test SPF records to avoid disruptions in email delivery.

SPF flattening

SPF can seem a little perplexing, particularly when you’re tasked with the somewhat unconventional process of flattening multiple SPF records into a single DNS entry. Many individuals opt for multiple entries, although this isn’t strictly aligned with SPF specifications.

To illustrate, if you’re configuring an SMTP.com sender, their recommendation might look like this:

v=spf1 include:_spf.smtp.com ~all

On the other hand, Google Workspace might advise you to use:

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

The correct way to address this situation is to merge these records, leading to:

v=spf1 include:_spf.google.com include:_spf.smtp.com ~all

If you’re looking for more in-depth guidance, you can explore valuable insights in this guide: SPF Best Practices.

Google Workspace DKIM records

Google Workspace DKIM records are a set of DNS records used to authenticate email messages sent from your domain through Google Workspace (formerly known as G Suite). DKIM (DomainKeys Identified Mail) is an email authentication method that uses a cryptographic signature to help ensure that an email message was not forged or tampered with during transmission.

To set up DKIM for Google Workspace, you need to add a set of DKIM records to your domain’s DNS settings. These records include a public key that is used to verify the cryptographic signature on outgoing email messages.

Here are the steps to add DKIM records for Google Workspace:

1. Sign in to your domain’s DNS management console.
2. Locate the DKIM records provided by Google Workspace. You can find these records in the Google Workspace Admin console under Apps > Google Workspace > Gmail > Authenticate email.
3. Add the DKIM records to your domain’s DNS settings. You will need to create a new DNS TXT record for each DKIM record provided by Google Workspace.
4. Wait for the changes to propagate. It may take up to 48 hours for the new DNS records to be available globally.

Once you have added the DKIM records to your domain’s DNS settings, email messages sent from your domain through Google Workspace will be signed with a DKIM signature. Receiving mail servers can then verify the signature to help ensure that the messages are authentic and have not been tampered with during transmission. This can help improve email deliverability and reduce the likelihood of your messages being flagged as spam or phishing attempts.

General Structure of a DKIM Record

A DKIM record typically includes information about the public key used to generate the digital signature. Here’s a general structure of a DKIM record:

selector._domainkey.yourdomain.com. IN TXT “v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBA…”

Let’s break down the components:

• selector: DKIM allows you to have multiple sets of keys for different purposes. The selector specifies which set of keys the recipient should use to verify the signature.
• _domainkey: This is a fixed string indicating that the TXT record is a DKIM record.
• yourdomain.com: This should be replaced with your actual domain.
• v=DKIM1: This indicates the DKIM version being used.
• k=rsa: Specifies the public key algorithm. RSA is a common choice.
• p=: This is where the public key itself is provided. It’s a long string of characters that represents the cryptographic key used to generate the DKIM signature.

To learn more about preventing email spoofing and spam using DKIM, you can read the following resource: Increase security for outgoing email with DKIM

Google Workspace DMARC records

Important: Configure Domain Keys Identified Mail (DKIM) and Sender Policy Framework (SPF) before configuring DMARC. DKIM and SPF should be authenticating messages for at least 48 hours before turning on DMARC.

DMARC is an email authentication protocol that helps verify the legitimacy of email messages sent from your domain. It accomplishes this by checking whether the domain used in the “from” email address of the message aligns with Domain Keys Identified Mail (DKIM) signatures within the message. If this alignment is successful, and the DKIM is passing, DMARC considers the email safe and passes it along.

DMARC General Structure

Let’s break down the components:

• _dmarc: This is a subdomain used for DMARC records.
• yourdomain.com: Replace this with your actual domain.
• v=DMARC1: This indicates the DMARC version being used.
• p=none: This is the policy applied when an email doesn’t pass DMARC checks. It can have values of none, quarantine, or reject.
  • none: No specific action is taken.
  • quarantine: The email might be treated with suspicion.
  • reject: The email should be rejected.
• rua=mailto:your@email.com: This is the email address to which aggregate reports (summaries of DMARC activity) are sent. The reports provide information about how your domain’s emails are being handled by receivers.
• ruf=mailto:your@email.com: This is the email address to which forensic reports (detailed reports about individual messages that fail authentication) are sent.
• fo=1: This option specifies the reporting options for failed authentication. 1 requests that only aggregate reports are sent, while 0 requests that both aggregate and forensic reports are sent.

Here’s an example of a more complete DMARC record:

_dmarc.yourdomain.com. IN TXT “v=DMARC1; p=reject; rua=mailto:reports@yourdomain.com; ruf=mailto:forensics@yourdomain.com; fo=1”

In this example, the DMARC policy is set to reject, meaning that any email failing DMARC checks should be rejected. Aggregate reports are sent to reports@yourdomain.com, and forensic reports are sent to forensics@yourdomain.com.

DMARC allows domain owners to have better control over their email ecosystem, reduce phishing, and receive valuable information about how their emails are being handled by receivers. It’s important to note that DMARC policy enforcement is gradual, and it’s recommended to start with a policy of none for monitoring before moving to quarantine or reject. This allows you to assess the impact on legitimate email traffic before implementing stricter policies.

Complex Scenarios and Multiple Senders

DMARC implementation can become complicated when you have multiple email systems sending messages on behalf of your domain or subdomain. If you have p=reject set up, it’s vital to ensure that all sending systems are properly configured to align with DMARC standards.

Consider this common scenario: You send emails from “mail.domain.com” using a service like Campaigner, but you also have a Google mailbox for the same email address. Campaigner is configured to sign DKIM for “mail.domain.com.” However, your Google mailbox may not be configured to do the same unless you follow Google’s instructions, as provided here.

If you haven’t configured your Google mailbox properly, any emails you send from Google won’t align with DMARC standards, causing DMARC to fail.

The Ideal DMARC Setup

To ensure the smooth operation of DMARC, follow these steps:

1. Configure Your ESP: Follow your Email Service Provider’s (ESP) instructions to ensure it signs DKIM with the sub/domain used in the “from” email.
2. Configure Google Workspace: If you use Google Workspace for your email, follow the instructions to make sure your Google mailbox aligns with DMARC standards.
3. Set DMARC to p=none: Initially, set your DMARC policy to “p=none.” This is a safe starting point as it doesn’t disrupt email delivery.
4. Test and Monitor: Send test emails from both your ESP and Google Workspace, and verify that DKIM passes and aligns with the sub/domain used in the “from” email.
5. Switch to p=reject: If the test results are positive for both systems, you can confidently switch your DMARC policy to “p=reject.”

In cases where the test results are not favorable, carefully investigate and resolve any errors before transitioning to the “p=reject” policy.

If you need help with publishing DMARC, you can find support at http://dmarc.org.

Learn how to enhance security against forged spam using DMARC, you can refer to the following resource: https://apps.google.com/supportwidget/articlehome?hl=en&article_url=https%3A%2F%2Fsupport.google.com%2Fa%2Ftopic%2F2752442%3Fhl%3Den&assistant_id=generic-unu&product_context=2752442&product_name=UnuFlow&trigger_context=a

Setting up DNS Records on Earnware

1. Navigate to the “Domains” page where you can check if all the necessary DNS records are present for your domain. Click on the domain name that you want to verify and ensure that all the required DNS records are present. Please note that DMARC may not be included in the detailed records, but it will be added later in the setup process.
2. To set up the DNS records, you can use the information provided on the Earnware and add them to your DNS hosting provider. Ensure that you have entered the records accurately to avoid any errors in the setup process.
3. After adding the DNS records, you can proceed to send a test email and confirm that DKIM is passing correctly. This step is essential as it ensures that the DNS records have been set up correctly and that your domain is signing its own DKIM. If DKIM is not passing, then the records need to be rechecked and corrected.
4. Once you have confirmed that DKIM is passing, you can proceed to add DMARC to your DNS records. DMARC is essential in ensuring that your email campaigns are delivered to your subscribers’ inbox and not marked as spam. Therefore, it is important to add DMARC to complete the setup process.

In conclusion, following these steps will ensure that your domain is set up correctly on Earnware, and your email campaigns are delivered to your subscribers’ inbox without any issues.

Setting up DNS records on Campaigner

For guidance on configuring Campaigner’s DNS records, you can obtain assistance at https://knowledge.campaigner.com/article/1784-dkim-spf-and-dmarc.

Impact of Misconfiguration

Misconfigured email authentication can have significant impacts on your email deliverability. If your emails fail authentication checks, they may be marked as spam, or even blocked entirely by receiving email servers. This can negatively impact your email marketing campaigns, customer support, and general communication.

Why Email Authentication Is Important?

A well-established foundation of properly configured DKIM, SPF, and DMARC records is essential for the success of your email campaigns and the protection of your domain. These records not only ensure that your emails reliably reach their intended recipients but also play a crucial role in preserving your brand’s reputation, thereby enhancing your organization’s credibility in the digital landscape.

Ensuring Email Deliverability to Subscribers:

• Legitimacy and Trust: Properly configured DKIM and SPF records authenticate your emails, assuring internet service providers (ISPs) and email receivers that your messages are legitimate. This authenticity builds trust, leading to higher email deliverability rates, as ISPs are more likely to route authenticated emails to subscribers’ inboxes rather than spam folders.
• Reducing Spoofing and Phishing: These records act as formidable shields against email spoofing and phishing attempts, providing subscribers with a layer of security. By confirming the sender’s identity, subscribers can be confident that the emails they receive are genuinely from your organization, protecting them from malicious impersonation.

Protecting Your Domain:

• Preventing Domain Spoofing: DMARC, when correctly set up alongside DKIM and SPF, combats domain spoofing. It enforces policies that dictate how unauthenticated emails from your domain should be handled, reducing the chances of cybercriminals abusing your domain for malicious activities.
• Enhancing Reputation: A well-configured DMARC record enables you to receive feedback reports, offering insights into email authentication failures. This empowers you to proactively address issues, thereby enhancing your domain’s reputation and credibility.
• Protecting Your Brand: By protecting your domain from abuse, you safeguard your brand’s image and reputation. A secure domain reassures subscribers and partners that their interactions with your brand are safe, fostering trust and loyalty.