" dkim Archives - LuxSci

Posts Tagged ‘dkim’

How Can I Prove an Email was Sent to Me?

Tuesday, January 16th, 2024

Almost everyone has been in this situation: someone claims to have sent you an email message, but you look in your inbox and don’t see it. As far as you know, you never got it. How can you prove an email was sent?

searching for an email

How to Prove That an Email was Sent

So, where do you start? As the purported recipient of an email message, the easiest way to prove that a message was sent to you is to have a copy of that message. It could be:

  1. In your inbox or another email folder
  2. A copy in your permanent email archives

 Sometimes, missing emails are caused by simple user errors. The obvious place to start the search is in your inbox and email folders. It’s also a good idea to check your email filtering and archival services. It’s possible that your email filtering system accidentally flagged the message as spam or sent it to quarantine. If it’s not there, check your email archival system. That should capture a copy of all sent and received messages. 

Hopefully, that will solve the issue. If it doesn’t, it’s worth stepping back to understand where the email could have gone and where you should turn next to solve the problem.

What happened to the email?

In reality, there are only a few things that could have happened:

  1. The recipient never sent the message.
  2. The recipient did send the message, but it did not reach you.
  3. The message did make it to you, but it was accidentally or inadvertently deleted (or overlooked).

Let’s begin with what you can check and investigate. Start your search soon. The more time that elapses, the less evidence you may have, as logs and backups get deleted over time.

Did the recipient actually send the message?

First, you should know that the sender could have put tracking on the message so that they were informed if you opened or read it (even if you are unaware of the tracking). In such cases, the sender can disprove false claims of “I didn’t get it!” If you are concerned about an email being ignored, use read recipients or tracking pixels to confirm email delivery.  

If you never saw the message, do what we discussed above and start searching your email folders for it. It could have been accidentally moved to the wrong folder or sent to the Trash folder. If you have a folder that keeps copies of all inbound emails (like LuxSci’s “BACKUP” folder), check there too. Check your spam folder and spam-filtering system. Your spam-filtering system may also have logs that you can search for evidence of this message passing through it. Finally, check any custom email filters you may have set up with your email service provider or in your email programs. If you have filters that auto-delete or auto-reject some messages, see if that may have happened to the message in question.

The searches above are straightforward; you can do many of them yourself. Often, they will yield evidence of the missing message or explain why you might not have received it.

Maybe the email was sent but didn’t make it to you?

Email messages leave a trail as they travel from the sender to the recipient. This trail is visible in the “Received” email headers of the message (if you have it) and in the server logs at the sender’s email provider and your email provider. If you know some aspects of the message in question (i.e., the subject, sender, recipient, and date/time sent), you can ask your email service provider to search their logs to see if there is any evidence of such a message arriving in their systems. This will tell you if such a message reached your email provider. However, email providers can typically only search the most recent one to two weeks of logs. So, if the message in question was from a while ago, your email service provider may be unable to help you (or may charge you a lot of money to manually extract and search archived log files if they have them). 

If your email provider has no record of the message or cannot search their logs, you (or the sender) can ask the same question of the sender’s email provider. If they can provide records of such an email being sent through their system, that will prove the email was sent.

The log file analysis provided by the email providers could also explain why you didn’t get the message. Your email address might have been spelled wrong, there could have been a server glitch or issue, etc. However, if the message was sent long ago, the chance of learning anything useful from the email provider is small. Also, if you use a commodity email provider such as AOL, Yahoo, Outlook, Gmail, etc., you may find it impossible to contact a technical support person and have them perform an accurate and helpful log search. Premium providers, like LuxSci, are more likely to support your requests. 

The last thing you can do is have the sender review their sent email folders for a copy of that message. If they have it, that can indicate that they sent it and can reveal why you didn’t get it (i.e., wrong email address, content that would have triggered your filters, etc.). However, be wary. It is easy to forge a message in a sent email folder, so it should not be considered definitive proof that the message was sent. And, even so, just because the message was sent, it does not prove it ever made it to your email provider or inbox.

The recipient never actually sent the email message

If the sending event was recent, then the data from your email service provider can prove that the message did not reach you, but that doesn’t prove that it was not sent. The sender may claim that they do not have a record of sent messages and that their email provider will not do log searching, and that may also be true. At this point, you are stuck without a resolution. 

While email is a reliable delivery system, there are many ways for messages not to make it to the intended recipient. Whether it was not sent or was sent and never arrived, the result is the same- no message for you. As a result, it’s best not to send legal notices or other important documents only by email. Using read receipts and other technologies when sending important messages can help increase confidence that an email was sent and received. Still, there is no foolproof way to guarantee email delivery.

How Do I Prove the Email Sender’s Identity?

A separate but related question is, how can I be sure the sender is who they say they are? Social engineering is rising, and cybercriminals can use technology to impersonate individuals and companies. If you are questioning whether the sender actually sent the message to your inbox (or if it is from a spammer or cybercriminal), it is necessary to perform a forensic analysis of the email headers (particularly the Received lines, DKIM signatures, etc.) and possibly get the sender’s email provider involved to corroborate the evidence. To learn more about how to conduct this analysis, please read: How Spammers and Hackers Can Send Forged Email.

Tags: dkim, email, email security, fraud, lost, missing, sent, tracking
Posted in LuxSci Library: The Technical Side of Email
No comments »

Preventing Email Forgery Part Three: DMARC

Tuesday, December 19th, 2023

In our previous two posts in this series, we examined how SPF and DKIM can help limit forged email messages by looking at the IP address and validating if the message was sent from an approved source based on digitally signed messages. We found that while SPF and DKIM can effectively prevent email fraud and forgery, weak implementations can make them vulnerable to attackers.

That’s where DMARC comes in. When properly implemented, DMARC provides instructions for what email filters should do with messages that fail SPF or DMARC. 

implementing DMARC in DNS

DMARC: A Simple Explanation

When using SPF and DKIM, email filters check if messages pass or fail SPF and DKIM. They use the DNS-published strictness settings to help them determine what to do next. How a particular filter is implemented determines what happens, leading to varied and inconsistent results.

So, what does DMARC do?

A DMARC policy allows a sender to indicate that both SPF and DKIM protect their emails and tells a receiver what to do if neither of those authentication methods passes – such as junk or reject the message. DMARC removes the guesswork from the receiver’s handling of these failed messages, limiting or eliminating the user’s exposure to potentially fraudulent and harmful messages. DMARC also provides a way for the email receiver to report to the sender about messages that pass or fail DMARC evaluation.

In practical terms, with a DMARC policy published in DNS:

  1. The message must pass either SPF or DKIM but does not need to pass both.
  2. This resolves the deficiencies of SPF (forwarding) and DKIM (inadvertent message modification) by allowing compensation via the other mechanism.
  3. Sender policies can specify what to do with messages not passing SPF and DKIM. There are three options: do nothing, quarantine them, or reject them. There is no longer any implementation-specific ambiguity on what filters should do and when.

Setting up DMARC

The domain owner must properly set up the DNS records to use DMARC (as with all anti-fraud solutions for email). If you cannot access the domain settings, you will be unable to update your DNS settings and will not be able to use DMARC.

DMARC is set up by adding special entries to the published DNS settings for the domain. You can use a tool, such as this DMARC Record Assistant, to create the DMARC DNS record for your domain.

We will not spend time on the details of the configuration or setup here. Instead, we will look at the utility of DMARC and its limitations.

The Benefits of DMARC

Once DMARC is set up, it helps reduce fraudulent emails from a domain. Simple forged spam and basic phishing attacks are curtailed more effectively with DMARC than with SPF and DKIM alone. Using DMARC combines them into a more comprehensive check with a consistent, well-defined failure state (e.g., reject or quarantine).

DMARC shines when implemented by domain owners using weak SPF and DKIM records. It allows email servers to accept that one of these validation schemes may fail while still requiring that the other one passes for the message to be considered legitimate. This is excellent progress.

DMARC is recommended for every domain owner and email filtering system. However, you must have control over all of the sources of messages from your domain name.

An interesting side effect is that, in some aspects, DMARC can make a domain more susceptible to determined forged emails!

The Limitations of DMARC

This is counterintuitive. Combining DKIM and SPF into a unified, complementary policy set that allows each to compensate for the other’s weakness is a fantastic idea and does a great job. However, a side effect of this technique in determining fraud is that it requires only one DKIM or SPF record to pass, NOT BOTH. In fact, there is no way to use DMARC to require that both must pass.

How Can Attackers Bypass DMARC?

An attacker only needs to find a way to pass one validation check to bypass DMARC. Note that this is only worse than separate use of SPF and DKIM if your SPF and DKIM rules are both strict (if it doesn’t pass — “drop it”). In most other cases, it’s the same or better than using both technologies separately.

Looking at our previous analyses of SPF and DKIM, an attacker could generate a forged email that passes DMARC if:

  1. They can send from an IP address allowed under the forged sender domain’s SPF policy. This can be done using the same email provider as the sender.
  2. They can send you a message from one of the servers authorized by the DKIM for the domain. If that server does not care who initiated the message but will sign any messages going through it with the proper DKIM keys, then the message will look legitimate. If the attacker signs up with the same email provider used by the forged domain and that provider’s servers do not restrict DKIM key usage, they can send an email from those same servers as the legitimate account and have their messages adequately signed.
  3. The attacker can compromise any sender’s workstations, email servers, or vendor’s email servers.

So, it requires a determined attacker with some knowledge of the sender’s infrastructure and some ingenuity to get past DMARC.

In addition, there is another way they can easily get past DMARC:

  1. If the sender’s domain has DMARC, SPF, and DKIM DNS records, if the recipient’s spam filters do not pay attention to DMARC (or the others), then these settings will be all for naught, and the forged message will still appear legitimate.

A determined attacker will gain knowledge both of the anti-fraud settings of the sender’s domain and of the capabilities of the recipient’s systems. The weaker the filters, the easier the attacker’s job can be.

What Else Can We Do to Prevent Email Forgery and Fraud?

Technologies are getting better and better at preventing email fraud, but none of them are foolproof. SPF and DKIM are implemented inconsistently, and DMARC is not well-supported across email filters. DMARC records are also not published for a majority of domains. Many that publish them have “no nothing” records designed to test the waters and gain telemetry on what messages they sent would fail DMARC.

Beyond using these technologies and being vigilant, some additional techniques can be used to lock down the identities of message senders. In the last article in this series, we shall see what some of these are.

Read next: Stopping Forged Email 4: Your Last Resorts

Tags: dkim, DMARC, dns, Domain-based Message Authentication, email fraud, email security, Reporting and Conformance, spam, spf
Posted in LuxSci Library: The Technical Side of Email
No comments »

Preventing Email Forgery Part Two: DKIM

Tuesday, December 19th, 2023

In our next post in this series, we look at another way to prevent forged email: DKIM. By using encryption techniques and digital signatures, the sender’s servers can transparently “sign “a message so that you can verify the source and ensure the message has not been modified. DKIM works together with SPF to stop fraud and improve email security.

email alert warning

DKIM – Domain Keys Identified Mail: A Simple Explanation

DKIM stands for “Domain Keys Identified Mail.” Actually, the acronym can be further expanded to “Domain-wide validation Mail Identity through use of cryptographic Keys.” To understand DKIM, we need to pause and look at what we mean by “cryptographic keys” and how they can be used.

Cryptographic Keys

In security, there is a concept called symmetric encryption. Users pick a password and use a cipher to convert a regular (plaintext) message into an encrypted (ciphertext) message. Someone else who knows the password and cipher can reverse the process to get the regular message back in plaintext. 

Another prevalent but more complex concept is asymmetric encryption. Using this method, one can create a key pair or a combination of two keys. A message encrypted using Key One can only be decrypted with Key Two and vice versa. We typically call Key One our “private key” because we keep that safe and secret. Key Two is our “public key” and can be accessed by anyone.

What are the benefits of asymmetric encryption?

  1. Signatures: Anything encrypted using Key One can be decrypted by anyone. If they can decrypt it, that proves that you sent it. Only you have the private key, and thus, only you could have encrypted it in the first place.
  2. Encryption: Anyone can use your public key to encrypt a message that you can only open (using your private key).

How DKIM Works

DKIM uses asymmetric encryption for signing email messages. This validates the sender’s identity and ensures the message contents are not altered in transit. Below is a simple overview of how it works.

Message Sending:

  1. Make a Key Pair: The owners of the sender’s servers create a cryptographic key pair.
  2. Publish the Public Key: They publish the public key in the DNS records for their domain.
  3. Sign Messages: Using the private key, the sender’s servers look at selected message headers (including the sender’s name and address, the subject, and the message ID) and the message body, and they use a cryptographic “hash” function to make a unique fingerprint of this information. Any change to that data would change the fingerprint. This fingerprint hash is also encrypted using the private key. Then, it is added to the message as a new header called “DKIM-Signature.”

Message Receipt:

When you receive a message signed using DKIM, you know the purported sender, their IP address, and the additional DKIM-Signature. However, you cannot trust that the signature header is real or has not been tampered with. Fortunately, you do not have to trust it unquestioningly; DKIM allows you to verify it. Here is what happens on the recipient’s side:

  1. Receipt: The recipient’s inbound email server receives the message.
  2. Get the Signature: The encrypted DKIM fingerprint is detected and extracted from the message headers.
  3. Get the Key: The recipient’s server looks in the sender’s DNS settings to get the public DKIM encryption key.
  4. Decryption: The fingerprint is decrypted using the public key.
  5. Fingerprint Check: The recipient then uses the message body and the same headers as the sender to make another fingerprint. If the fingerprints match, the message has not been altered since it was sent.

As a result, you can verify the sender’s identity because:

  1. We know that the message has not been modified since it was sent. The sender’s name and address (among other things) are the same as when it was sent.
  2. We know the message was sent by a server authorized to send emails for the sender’s domain, as that server used the DKIM private key.

So, through encryption, we have a way to verify that the message was sent by a server authorized to send email from their domain, and thus, we have a solid reason to believe the sender’s identity. Furthermore, this validation does not rely on server IP addresses alone and thus does not share the weaknesses of SPF.

Setting up Domain Keys Identified Mail

It is up to the domain owner to configure their DNS settings for DKIM to be checked by the recipients. You must have access to the domain and the ability to update your DNS records to implement DKIM. 

DKIM is set up by adding unique entries to the published DNS settings for the domain. You can use a tool like this DKIM Generator to create your DKIM cryptographic keys and tell you what you should enter into DNS. Your email provider may have their own tools to assist with this process. The private key must be installed on their mail servers, and DKIM must be enabled. We recommend asking your email provider for assistance.

We will not spend time on the details of the configuration or setup here. Instead, we will look at the actual utility of DKIM, where it fails, and how attackers can get around it.

The Benefits of DKIM

Once DKIM has been set up and is used by your sending mail servers, it does a fantastic job with anti-fraud. It is more robust than SPF. It also helps ensure that messages have not been modified since they were sent. We can be sure who sent the message and what they said, while SPF does not provide any assurance that messages were unaltered.

DKIM is highly recommended for every domain owner and every email filtering system. However, as we shall see next, it’s not time to throw a party celebrating the end of fraudulent emails.

The Limitations of DKIM

While Domain Keys Identified Mail is significantly stronger than SPF on its own, it continues to have limitations in the battle against email fraud.

Identifying Email Sending Servers

To properly use DKIM, all servers that send emails for your domain must have it set up and have keys for your domain. This can be challenging to implement if you use vendors or have partners send emails on your behalf. If DKIM cannot be used, emails should be sent using a different domain or a subdomain so that the primary domain can be fully DKIM-enabled and its DNS can tell everyone that DKIM signatures must be present on all messages. You want to be strict with DKIM usage in a way that is hard to do with SPF.

If you cannot be strict, then DKIM allows you to be soft, which indicates that signatures may or may not be present. In such cases (like with SPF), the absence of a DKIM signature does not make a message invalid. However, if your DKIM setup is soft, it makes forgery simple. 

Inter-Domain Forgery

DKIM checks only the domain name and the server. If there are two different people in the same organization, Fred and Jane, either can send email legitimately from their @domain.com address using the servers they are authorized to use for domain.com email.

However, if Fred@domain.com uses his account to send a message forged from Jane@domain.com, the DKIM will check out as okay, even if DKIM is strict.

DKIM does not protect against inter-domain forgery at all. Note: using separate DKIM selectors and keys for each unique sender would resolve this problem (and the next one), but this is rarely done. 

Same Email Provider: Possible Shared Servers Forgery

If Fred@badguy.com and Jane@goodguy.com were using the same email service provider and servers, Jane’s goodguy.com domain would be set up with DKIM. The email provider’s servers are also set up to sign messages from @goodguy.com with appropriate DKIM signatures. What happens when Fred@badguy.com logs in to his account and sends a message pretending to be from Jane?

 The answer depends on the email provider:

  1. The provider could prevent Fred from sending emails purporting to be from anyone except himself. This would solve the problem immediately, but it is very restrictive, so many providers do not do this.
  2. The provider could associate DKIM keys to specific users or accounts (this is what LuxSci does). Fred’s messages would never be signed by valid the “goodguy.com” DKIM keys, no matter what. This also solves the problem.

However, if the provider’s servers are not restrictive in one of these (or a similar way), Fred’s forged email messages will be DKIM-signed with the goodguy.com signature and appear DKIM-valid.

Legitimate Message Modification

DKIM is very sensitive to message modification. DKIM signature checks will return invalid if even one character has been changed. This is generally good, but email filtering systems may break DKIM. They often read and “re-write” messages in transit where the actual message content is unchanged, but specific (MIME) metadata is replaced with new data. This breaks DKIM, and it can happen more frequently than expected.

Good spam filters check DKIM before modifying messages. Still, if you have multiple filtering systems scanning messages, the DKIM checks of later filters may be broken by the actions of earlier filters. 

DKIM does not protect against Spam

This is not a limitation of DKIM, but it’s worth noting anyway. All DKIM does is help you identify if a message is forged or altered. Most spammers are savvy. They use legitimate domain names and create valid DKIM records to look legitimate.

In truth, this does not make them look less spammy; it just says that the messages are not forged. Of course, if the spammer tries to get by your filters by forging the sender address to pretend that they are you or someone you know, then DKIM can help.

How Attackers Subvert DKIM

So, in the war of escalation where an attacker tries to get a forged email message into your inbox, what tricks do they use to get around sender identity validation by DKIM?

The protections afforded by DKIM are more significant than those provided by SPF. From an attacker’s perspective, it all comes down to what sender’s email address (and domain) they are forging. Can they pick an address to construct an email that will evade DKIM?

  1. If DKIM is not set up, it’s easy to forge the email. 
  2. If DKIM is set up as weak, the attacker can send a forged message with a missing DKIM signature, which will look legitimate.
  3. Suppose the attacker can send a message from one of the servers authorized by the DKIM for the domain. If that server does not care who initiated the message but will sign any messages going through it with the proper DKIM keys, then the message will look legitimate. If the attacker signs up with the same email provider used by the forged domain and that provider’s servers do not restrict DKIM key usage, they can send an email from the same servers and have their messages properly signed. This makes the attacker’s email look valid even if the forged domain’s DKIM records are strict.

 An attacker’s options are much more limited with DKIM. They can only send fraudulent messages from domains with no or weak DKIM support, send through non-restrictive shared email servers, steal the private key used by the sender’s DKIM, or compromise the email account of someone using the same email domain as the address that is to be faked.

The situation is better, but not perfect. Many organizations leave their DKIM configuration weak. They would rather take a chance on forged emails than have legitimate messages be missed due to accidental message modification or because they were sent from a server without DKIM.

We will see in our next post how one can use DMARC to combine the best features of DKIM and SPF to enhance forged email detection further and where the gaps that attackers use remain.

Read next: Preventing Email Forgery Part 3: DMARC

Tags: dkim, DMARC, dns, Domain Keys Identified Mail, email, email forgery, email security, forgery, fraud, spam, spf
Posted in LuxSci Library: The Technical Side of Email
No comments »

Preventing Email Forgery Part One: SPF

Tuesday, December 19th, 2023

Some of the most dangerous cybersecurity threats originate with email, costing businesses millions of dollars annually. How can you increase your email security and prevent email fraud?

In this series, we will look at how to use DNS records to prevent email forgery. The first and simplest method is SPF – Sender Policy Framework. Below, we shall look at what it does, how it works, how to set it up, and what some of its deficiencies are. In future articles, we will look at the other techniques. 

spam warning on laptop

Sender Policy Framework: A Simple Explanation

Simply put, SPF is a way for a domain owner to publish information indicating what servers (internet addresses) are authorized to send email from that domain. Recipients can check the email source against this authorization list. If the server is on the list, the message is likely legitimate. If it is not on the list, the message could be forged. 

Setting up SPF

With SPF (as with all anti-fraud solutions for email), it is up to the domain owner to set up the SPF authorization list. Identifying who manages the domain is often the most significant barrier to implementing SPF. Without access to the DNS settings, creating the SPF authorization list is impossible.

To set up SPF, the domain administrator adds a special entry to the published DNS settings. If you want to set up SPF for your domains, use the SPF Wizard. You can also ask your email provider for assistance. 

We will not spend time on the details of the configuration or setup here. Instead, we will look at the actual utility of SPF, where it falls on its face, and how attackers can get around it.

The Benefits of Sender Policy Framework

Once SPF has been set up, it does an excellent job of helping identify forged emails. It verifies that the sending server is authorized to send. The use of SPF is highly recommended for every domain owner. However, as we shall see next, SPF is insufficient to prevent all email fraud.

SPF Limitations

Sender Policy Framework has some significant limitations in stamping out email forgery. Below, we discuss some of the ways it falls short. 

Identifying Authorized Sending Server Addresses

Identifying all your email-sending servers may not be an issue if you are a small or well-controlled organization. However, it can be more difficult for larger organizations because of their size and use of partners and vendors to send emails on their behalf. In that case, making a complete SPF authorization list is practically impossible.

A related issue is that sometimes, we cannot specify all the authorized servers in SPF. For example, you can only have 10 DNS lookups in an SPF check. If your SPF record must be more complicated than that due to all of the possible organizations that send emails for you, then you must either refrain from using SPF or leave some legitimate sending servers off the list.

 In cases where you cannot make a complete list, you can configure the SPF record as “weak.” This means that if SPF matches, then the message is legitimate. But if the weak SPF check fails because it comes from an unauthorized server, it might or might not be legitimate.

Forwarded Messages Appear Illegitimate

When a message is forwarded, the from address does not change, but the sending server does. For example, if you receive a message from Bank of America and then forward it to your friend, it is now your email server sending a message that purports to be from bankofamerica.com.

If bankofamerica.com’s SPF records were set as strict, then your friend’s email server would identify the forwarded message as forged and mark it as spam or fraud. In most cases, that is not desirable. While there is a technology that allows forwarding to get around this (SRS – Sender Rewriting Scheme), it has yet to be widely adopted. 

For this reason, most domain owners set up their SPF records as weak (indicating that if the SPF check fails, the message could still be legitimate).

Inter-Domain Email Forgery

Because SPF checks only the domain name and the server, two different people in the same organization, Fred and Jane, can send emails legitimately from their @domain.com address using the same authorized servers for domain email.

However, if Fred@domain.com uses his account to send a message forged from Jane@domain.com, the SPF will check out as okay, even if the SPF is set as strict. 

SPF does not protect against inter-domain forgery at all.

Same Email Provider: Shared Email Servers Forgery

If two people using different domain names have the same email provider, they may also have the same SPF records. Email providers usually have their customers use a standard SPF record indicating that messages from any of the provider’s servers are okay. In this case, it may be possible for any user of that email provider to send a forged message purporting to be from another user in an unrelated domain and have the SPF check pass.

One way to avoid this issue is to use dedicated servers to send email from your domain. If your email provider allows it, you can accurately update your SPF list to indicate only the servers assigned to your account. Then, the SPF record would only reflect your sending and could not be corrupted by other customers of the email provider.

Sender Policy Framework does not protect against spam

This is not a limitation of SPF, but it’s worth mentioning in the context of email security. All SPF does is help you identify if a message is forged or not. Most spammers are savvy. They use their own domain names and create valid SPF (and DKIM and DMARC) records so that their email messages look more legitimate.

In truth, this does not make them look less spammy; it just says that the messages are not forged. Of course, if the spammer is trying to evade your filters by forging the sender address so that the sender is you or someone you know, then SPF can absolutely help.

How Attackers Subvert SPF

So, in the war of escalation where an attacker is trying to get a forged email message into your inbox, what tricks do they use to get around sender identity validation by SPF? 

As we have seen, most domains set up SPF weakly so that messages that fail SPF are not automatically flagged as invalid. From an attacker’s perspective, it all comes down to what sender’s email address (and domain) they are forging. Can they pick an address to construct an email that will make it past SPF?

  1. If the sender’s address does not have SPF configured, it’s easy for the attacker to impersonate.
  2. The message will look legitimate if the attacker can send a message from a server authorized by the SPF for the domain. If the attacker signs up with the same email provider used by the forged domain, they may be able to send an email from the authorized servers for the forged domain. This makes the attacker’s email look legitimate even if the forged domain’s SPF records are strict.
  3. If the forged domain’s SPF records are weak and the attacker can’t use an authorized server to make the message look valid, it doesn’t matter, as SPF failure won’t make their message look forged.

If the attacker has a choice of addresses to forge to achieve their ends, then it is likely that they can pick one that meets one of these three options.

How to Fix Sender Policy Framework?

SPF is helpful but not the sole solution for email fraud prevention. What else can you do?

A responsible domain owner who wants to protect their domain from forgeries and identify forged inbound emails takes additional steps, which we shall discuss in future articles. These include DKIM, DMARC, and other message signature and isolation techniques.

Read next: Preventing Email Forgery Part 2: DKIM

Tags: dkim, DMARC, dns, email forgery, email fraud, forged email, fraud, identity, sender policy framework, spam, spf, SRS
Posted in LuxSci Library: The Technical Side of Email
No comments »

New Email Authentication Requirements from Google and Yahoo: What You Need to Know

Tuesday, December 12th, 2023

Google and Yahoo have recently announced their latest updates aimed at reducing spam and spoofed emails.

These updates affect everyone sending emails to Google or Yahoo users. They apply fundamental authentication requirements to regular email, and further requirements apply to those sending higher volumes of bulk emails. These new requirements apply to all email platforms and service providers.

Please note: Many of these new requirements are technical in nature and will require access to your DNS management. You may learn more about these DNS concepts in this LuxSci blog: Understanding DNS Configurations for Email Security: A Guide to SPF, DKIM, and DMARC Records.

As a reminder, it is imperative that you adhere to strong email best practices. Here’s what you need to continue doing on top of your email game:

All senders emailing Yahoo or Gmail:

  • Add DNS SPF records for every domain you use to send emails to authenticate your emails.
  • Add DNS DKIM Records for every domain you use to send emails to further authenticate your emails.

While many have added SPF records in 2023, it’s now crucial to also have DKIM records in place.

 For those sending large volumes of emails to Google or Yahoo users (over 5,000 messages on some days)

  • Complete the requirements required for all senders.
  • Implement DNS DMARC: Set up a DNS DMARC email authentication policy for your domains. You can set your DMARC enforcement policy to “none.”
  • Align Your Domains: Ensure the domain used for bounce processing (i.e., the “Return-Path”) matches/is aligned with your From domain in every email.
  • Include Easy Unsubscribe Options: Include a one-click unsubscribe option for marketing and subscription emails.

 

Google’s new requirements begin on February 1st, 2024, and Yahoo will follow in the first quarter of 2024. Aim to make these changes by the end of January 2024.

LuxSci customers will need to:

  • Ensure a DNS Sender Policy Framework (SPF) record.
  • Ensure a DNS DKIM record is in place.
  • Implement a DNS DMARC record.
  • For marketing and subscription emails, enable and use LuxSci’s “Unsubscribe Links” feature.
  • For those using LuxSci Bounce Processing, enable the user of a Custom Bounce Processing domain for every sending domain to ensure that these domains are aligned.

These steps will help ensure your emails continue to reach your audience effectively and responsibly. Without them, messages to Google and Yahoo! recipients may go directly to their Spam folders or be rejected.

As always, your LuxSci team is here to help clarify or provide further guidance. We are happy to support you and help you successfully navigate through these changes.

You may read more about these requirements at the following links:

Tags: dkim, DMARC, dns, email deliverability, google, high volume email, shv, spam, spf, yahoo!
Posted in LuxSci Library: The Technical Side of Email, New Feature Announcements
Comments Off on New Email Authentication Requirements from Google and Yahoo: What You Need to Know

« Older Entries