8 posts tagged with "Email security"

Overview​

BIMI (Brand Indicators for Message Identification) is an email specification that enables organizations to display their brand logo alongside authenticated emails in recipients' inboxes. BIMI leverages existing email authentication standards, such as DMARC, to verify the sender's identity, ensuring that only emails passing authentication can display the logo. BIMI enhances brand recognition, fosters trust in email communication, and helps combat phishing by visually confirming the legitimacy of the sender.

Key Functions of BIMI:​

1. Increased Brand Visibility: BIMI allows businesses to display their logo next to emails, increasing brand recognition and engagement.
2. Enhances Trust and Security: By linking logos to authenticated emails, BIMI helps recipients quickly identify trusted senders, reducing the risk of phishing.
3. Builds on DMARC Authentication: BIMI requires DMARC authentication to function, ensuring that email is correctly authenticated and aligned with the sender's domain.

BIMI Workflow​

1. DMARC Authentication:
   • BIMI requires that the sending domain has a valid DMARC policy with either a p=quarantine or p=reject policy in place. Only emails that pass DMARC authentication are eligible to display the brand logo.
2. DNS Query for BIMI Record:
   • After successful DMARC validation, the email client queries the domain's DNS for the BIMI record. This record contains the location of the sender's logo (in SVG format) that should be displayed in the recipient's inbox.
3. Logo Display:
   • If the email passes DMARC and the BIMI record is found, the recipient's mail client downloads the logo and displays it alongside the email in the inbox, reinforcing the sender's brand identity.
4. Verified Mark Certificate (VMC) (Optional):
   • Some email clients or providers may require a Verified Mark Certificate (VMC), which is an additional layer of security that verifies the logo has been certified by a trusted authority. This step is not mandatory for all implementations but adds credibility to the BIMI process.

BIMI DNS Record Details​

The BIMI record is a DNS TXT record that specifies the location of the brand's logo in SVG format. This record enables mail servers to retrieve the logo once DMARC authentication is successful.

Name​

default._bimi.[domain]

Example Value​

v=BIMI1; l=https://example.com/logo.svg

Mandatory Tags​

Optional Tags​

BIMI Logo Requirements​

BIMI requires that logos be in a specific SVG (Scalable Vector Graphics) format to ensure they are displayed consistently across different email clients. The logo must adhere to the following guidelines:

1. File Format: The logo must be in SVG format. It must not contain any scripts or external resources.
2. Dimensions: The SVG logo should fit within a square aspect ratio (e.g., 1:1) to avoid distortion when displayed.
3. Security: The SVG file should not include any potentially harmful elements (e.g., JavaScript, external links), as it will be served across different mail platforms.
4. Brand Recognition: The logo must be representative of the brand, typically the same one used in marketing, websites, or other official communications.

Verified Mark Certificate (VMC)​

A Verified Mark Certificate (VMC) is an optional component of BIMI that adds an extra layer of trust to the displayed logo. A VMC is a digital certificate issued by a trusted certification authority, verifying that the logo belongs to the brand and has been officially authenticated.

Benefits of a VMC​

• Logo Certification: Proves that the logo has been vetted and verified by a trusted third party, ensuring that the brand has the right to use it.
• Enhanced Trust: Helps email clients and recipients trust that the email is legitimate and not a phishing attempt.

Benefits of BIMI​

1. Brand Awareness:
   • By allowing organizations to display their logo next to their emails, BIMI increases brand recognition and recall, making it easier for recipients to identify trusted senders in their inbox.
2. Enhanced Trust and Engagement:
   • The presence of a familiar brand logo enhances recipient trust, improving email engagement rates and reducing the chances of email being flagged as spam.
3. Phishing and Fraud Prevention:
   • BIMI builds on top of DMARC, ensuring that only authenticated emails from verified domains can display the brand's logo. This helps recipients easily distinguish between legitimate emails and phishing attempts.
4. Strengthens Email Authentication:
   • BIMI encourages domain owners to adopt strong email authentication protocols, such as DMARC, by rewarding them with improved brand visibility in the inbox.

BIMI and DMARC​

BIMI requires DMARC (Domain-based Message Authentication, Reporting & Conformance) authentication with either a p=quarantine or p=reject policy for it to function. Only domains that have DMARC properly configured and whose emails pass authentication checks can display their logos via BIMI.

DMARC Configuration Example​

_dmarc.example.com. IN TXT "v=DMARC1; p=quarantine; rua=mailto:[email protected]"

BIMI helps incentivize companies to implement DMARC because having a correctly configured DMARC policy is a prerequisite for displaying logos via BIMI.

Challenges and Considerations​

Mail Client Support​

• Not all email clients or services currently support BIMI. Adoption is growing, but it's important to check whether your target audience's email platforms support BIMI logos. For instance, Gmail and Yahoo Mail are some of the prominent platforms that have implemented support for BIMI.

Logo Compliance​

• The SVG file must comply with BIMI's SVG specifications. If the logo file is not properly formatted or contains unsupported elements, it may not be displayed.

Requirement for DNSSEC​

• For domains using VMC, DNSSEC (DNS Security Extensions) is recommended to ensure the integrity of BIMI DNS records and protect them from spoofing attacks.

Conclusion​

BIMI (Brand Indicators for Message Identification) enhances the email ecosystem by allowing brands to display their logos in recipients' inboxes, improving trust and engagement while helping users quickly identify legitimate emails. By building on DMARC authentication, BIMI adds a visual element to email security and brand recognition. As more email clients adopt BIMI, its role in improving email marketing and security will continue to grow, making it a valuable tool for organizations of all sizes.

Overview​

DANE (DNS-based Authentication of Named Entities) is a protocol that enables domain owners to specify which TLS certificates should be trusted for a given service via DNSSEC (DNS Security Extensions). This adds an extra layer of security to TLS connections, ensuring that the certificate used in the communication is valid and matches what the domain owner has specified. DANE allows administrators to bind X.509 certificates (used in TLS) to their domain names securely using DNS.

Key Functions of DANE:​

1. Certificate Validation: DANE enables verification of TLS certificates directly through DNS, without relying solely on public certificate authorities (CAs).
2. Protection Against Misissued Certificates: Since the certificate is validated through a DNS record (protected by DNSSEC), it prevents attacks involving rogue or misissued certificates.
3. Strengthens TLS Security: DANE provides an additional layer of trust by ensuring that the domain owner controls which certificates are valid, thereby enhancing the integrity of TLS connections.

DANE Workflow​

1. DNS Query for TLSA Record:
   • A client initiating a TLS connection queries the domain's DNS to retrieve the TLSA record, which specifies which certificates are trusted for the domain.
2. DNSSEC Validation:
   • The DNS query for the TLSA record must be validated through DNSSEC to ensure the integrity of the response and prevent tampering or spoofing. Without DNSSEC, the security of DANE cannot be guaranteed.
3. TLS Certificate Verification:
   • Once the TLSA record is retrieved, the client checks the certificate presented by the server during the TLS handshake against the information in the TLSA record.
4. Connection Established:
   • If the certificate matches the one specified in the TLSA record, the TLS connection is established securely. If it does not match, the connection is either rejected or flagged as insecure.

DANE DNS Record Details​

The core of DANE is the TLSA (Transport Layer Security Authentication) DNS record, which specifies which certificate or public key should be used when establishing a TLS connection to a particular service (e.g., SMTP, HTTPS).

Name​

_port._protocol.[domain].[topdomain]

Example Value​

_443._tcp.example.com. IN TLSA 3 1 1 abc123...

TLSA Record Fields​

A TLSA record consists of four fields:

Usage Field Values​

Selector Field Values​

Matching Type Field Values​

DANE Record Examples​

1. Service Certificate Constraint (Usage 1)

   _443._tcp.example.com. IN TLSA 1 1 1 [hash-of-certificate]

   This specifies that the server must use a specific certificate, and the client should verify the SHA-256 hash of the certificate.

2. CA Constraint (Usage 0):

   _443._tcp.example.com. IN TLSA 0 0 2 [hash-of-issuing-ca-certificate]

   This specifies that the server's certificate must be issued by a specific CA whose SHA-512 hash is provided.

3. Domain-Issued Certificate (Usage 3):

   _443._tcp.example.com. IN TLSA 3 1 1 [hash-of-public-key]

   This allows the domain to act as its own certificate authority, issuing and using certificates without relying on third-party CAs.

Benefits of DANE​

1. Enhanced Security Through DNSSEC:
   • DANE leverages DNSSEC to ensure the integrity of DNS records, preventing attacks like DNS spoofing or man-in-the-middle attacks. By validating the TLSA records, clients can trust that the correct certificate is being used.
2. Protection Against Rogue CAs:
   • DANE can protect against rogue certificate authorities by allowing domain owners to specify which CAs are allowed to issue certificates for their domain or directly associate their own certificate with the domain.
3. Self-Issued Certificates:
   • With Usage 3, domain owners can use their own self-signed certificates, bypassing traditional public CAs while still maintaining a high level of security.
4. Flexibility for TLS Services:
   • DANE can be used with various services that support TLS (e.g., HTTPS, SMTP), providing flexibility in securing connections over different protocols.

Use Cases for DANE​

Email Security with DANE and SMTP​

DANE is commonly used to secure SMTP (email transmission). When paired with SMTP MTA-STS or STARTTLS, DANE ensures that email servers use the correct TLS certificate when establishing connections, preventing downgrade attacks.

HTTPS Validation​

DANE can also be used to validate certificates for HTTPS connections, providing an extra layer of trust beyond the traditional CA-based system.

DANE and DNSSEC​

DNSSEC (DNS Security Extensions) is critical to the functionality of DANE. Without DNSSEC, a TLSA record could be spoofed by an attacker, leading to the validation of a malicious certificate. DNSSEC ensures that the TLSA records retrieved by clients are authentic and have not been tampered with.

• DNSSEC uses a chain of trust, starting from the DNS root zone, to ensure that DNS records are signed and validated. When a client queries a TLSA record, DNSSEC ensures that the response has not been altered in transit.

Challenges and Considerations​

DNSSEC Requirement​

• DANE is only secure if DNSSEC is enabled and correctly configured for the domain. Without DNSSEC, DANE loses its trust model, as an attacker could spoof the TLSA record.

Limited Client Support​

• Although DANE offers robust security features, its adoption has been slower compared to other certificate validation mechanisms. Not all clients and services support DANE, and the infrastructure for DNSSEC is still growing.

Certificate Management​

• Domain owners must ensure that their TLSA records are kept up-to-date, particularly when certificates are renewed or reissued. Failure to do so can result in clients rejecting valid connections due to mismatched certificates.

Conclusion​

DANE (DNS-based Authentication of Named Entities) enhances the security of TLS connections by binding certificates to DNS records through DNSSEC. By allowing domain owners to specify which certificates should be trusted, DANE reduces the risk of man-in-the-middle attacks, rogue certificates, and misconfigurations. While DANE is primarily used for SMTP and HTTPS, its flexibility makes it applicable to any service that uses TLS, offering a more secure alternative to traditional certificate validation models.

Overview​

TLS-RPT (SMTP TLS Reporting) is a mechanism that enables domain owners to monitor issues related to the Transport Layer Security (TLS) encryption for email communication. It works by having mail servers send detailed reports about failed or downgraded TLS connections back to the domain owner, allowing them to detect misconfigurations or attacks (such as Man-in-the-Middle (MitM) attacks) in real time.

The reports provide visibility into delivery problems encountered by receiving email servers when negotiating encrypted connections using SMTP MTA Strict Transport Security (MTA-STS). This reporting mechanism helps ensure that messages are transmitted securely, improving both compliance and email security.

Key Functions of TLS-RPT​

1. Monitoring TLS Failures: Enables domain owners to receive daily reports of TLS connection failures and issues related to the security of their email transmissions.
2. Identifying Misconfigurations: Helps diagnose incorrect TLS settings on email servers or communication downgrades.
3. Preventing Downgrade Attacks: Detects when an attacker attempts to intercept or downgrade the security of an SMTP connection.

TLS-RPT Workflow​

1. DNS Lookup for TLS-RPT Policy:
   • Similar to DMARC, TLS-RPT is configured through a DNS TXT record. When a mail server encounters an issue with TLS, it checks for the presence of a TLS-RPT policy in the sender's DNS to determine where to send failure reports.
2. Mail Server Negotiates TLS:
   • When an email is transmitted, the sending and receiving mail servers attempt to negotiate TLS for encryption. If the TLS negotiation fails or is downgraded (e.g., due to a Man-in-the-Middle (MitM) attack), a report is generated.
3. Failure Report Generated:
   • If a connection fails to establish TLS, the receiving server generates a TLS-RPT report, detailing the issues encountered during the transmission.
4. Report Sent to Designated Address:
   • The report is sent to the domain owner's specified email address (configured in the DNS record), where it can be analyzed to address potential security issues.

TLS-RPT DNS Record Details​

The TLS-RPT policy is published in DNS under the _smtp._tls subdomain, and it defines the destination for TLS-RPT failure reports. The format of the DNS TXT record specifies where and how often reports are sent.

Name​

_smtp._tls.[domain].[topdomain]

Example Value​

v=TLSRPTv1; rua=mailto:[email protected]

Mandatory Tags​

TLS-RPT Aggregate Reports​

TLS-RPT reports are aggregate reports that summarize the results of TLS connection attempts. These reports are usually sent daily and include information about whether or not TLS was successfully negotiated during the transmission of email.

Report Format​

Reports are generated in JSON format and typically include the following key information:

• Organization Name: The name of the organization responsible for generating the report.
• Date Range: The time period during which the TLS failures occurred.
• Sending IP Addresses: The IP addresses of the sending servers.
• Receiving Host: The email host (MX server) that attempted the TLS connection.
• Failure Details: Information about why the TLS connection failed or was downgraded (e.g., expired certificates, mismatched TLS versions).

Example Report Structure​

{
  "organization-name": "Example Inc.",
  "date-range": {
    "start-datetime": "2023-09-01T00:00:00Z",
    "end-datetime": "2023-09-01T23:59:59Z"
  },
  "email-server": "mx.example.com",
  "failed-connections": [
    {
      "source-ip": "192.0.2.1",
      "receiving-host": "mx1.example.com",
      "failure-reason": "STARTTLS failure",
      "error-code": "TLS handshake failed"
    }
  ]
}

Benefits of TLS-RPT​

1. Improved Security Visibility: By receiving reports of TLS issues, domain owners gain valuable insight into the security posture of their email traffic.
2. Detection of Misconfigurations: TLS-RPT helps diagnose configuration issues, such as expired certificates, that prevent secure email transmissions.
3. Prevention of Downgrade Attacks: TLS-RPT can alert domain owners to attempted downgrade attacks, where an attacker forces a connection to fall back to an unencrypted state.
4. Proactive Issue Resolution: Allows domain administrators to proactively resolve problems with TLS configurations and ensure continued secure email transmission.

TLS-RPT and MTA-STS​

TLS-RPT is commonly used in conjunction with MTA-STS (SMTP MTA Strict Transport Security), which enforces the use of TLS for email transmissions. While MTA-STS ensures that email servers only communicate over secure connections, TLS-RPT reports provide insight into whether the policy is working as intended.

Additional Details​

Report Frequency​

The TLS-RPT record does not specify a frequency for sending reports, but they are typically sent daily by receiving servers.

Report Analysis​

Reports help administrators detect recurring issues with specific mail servers or geographic regions, allowing them to address these problems and improve email deliverability and security.

Conclusion​

TLS-RPT is an essential tool for maintaining secure email communications. By allowing domain owners to receive detailed reports on failed TLS connections, it helps improve the overall security of email traffic and prevent interception or manipulation of messages. Used alongside MTA-STS, it offers a comprehensive solution for enforcing and monitoring secure email delivery.

Overview​

MTA-STS (Mail Transfer Agent Strict Transport Security) is a security protocol designed to improve the security of email in transit. It allows domain owners to declare a policy that enforces the use of TLS (Transport Layer Security) for SMTP connections to their domain. MTA-STS prevents attackers from intercepting or tampering with email communications by requiring that messages sent to the domain be encrypted and validated.

MTA-STS is an enhancement to the opportunistic encryption used in SMTP, which by default does not guarantee encryption, as connections can downgrade to plaintext without strict enforcement. With MTA-STS, senders can ensure that the receiving domain mandates the use of encryption, thus increasing the security of email delivery.

Workflow​

1. Policy Declaration: The receiving domain publishes an MTA-STS policy via a DNS record and a web server that hosts the policy file.
2. Sender Queries the DNS: When an MTA sends an email to the receiving domain, it first queries the DNS to check if an MTA-STS policy is available.
3. Fetching the Policy: If the DNS query returns a valid MTA-STS policy record, the sending MTA fetches the policy from the specified HTTPS endpoint.
4. Policy Enforcement: The sending MTA checks the policy, which specifies whether to require TLS for email delivery. If the policy enforces strict TLS, the email will only be sent if a secure TLS connection can be established. If TLS cannot be negotiated, the email is not delivered.

Pros​

• Prevents Downgrade Attacks: MTA-STS ensures that emails are transmitted over secure, encrypted channels, preventing attacks such as STARTTLS downgrades.
• Encrypted Delivery: MTA-STS enforces TLS encryption for emails in transit, ensuring that sensitive data is not transmitted over plaintext connections.
• Mitigates Man-in-the-Middle (MITM) Attacks: By enforcing TLS and requiring certificate validation, MTA-STS reduces the risk of MITM attacks, where attackers could intercept or modify emails in transit.

Cons​

• Limited Support: Not all mail servers fully support MTA-STS yet, which limits its adoption and may not provide complete protection in all cases.
• DNS & HTTPS Configuration: Correctly configuring DNS and hosting the policy on an HTTPS server can be complex, especially for smaller organizations without technical expertise.
• No Email Bounce for Policy Failures: If a sender cannot deliver an email due to a failure to negotiate a TLS connection under MTA-STS, the message might not be delivered, but this failure may not always result in a bounce-back notification.

Details​

DNS Record​

MTA-STS is enabled by creating a DNS TXT record and hosting the policy file on a secure HTTPS server. The DNS record tells sending MTAs that the receiving domain supports MTA-STS and provides the URL where the policy file can be found.

DNS TXT Record​

The DNS TXT record must be created at _mta-sts.[domain].[tld] and includes the version of the policy and the URL for fetching the policy file.

Example:

_mta-sts.example.com. IN TXT "v=STSv1; id=2021090100"

MTA-STS Policy File​

The policy file is hosted on a secure HTTPS server at https://mta-sts.[domain]/.well-known/mta-sts.txt. This file defines the rules for enforcing TLS connections. It includes parameters such as the version of the policy, the mode (enforce or testing), and the list of valid MX hosts.

Example Policy File​

version: STSv1
mode: enforce
mx: mail.example.com
max_age: 86400

Policy Modes​

MTA-STS supports different modes to allow for gradual rollout and testing.

Example MTA-STS Workflow​

1. A sending mail server attempts to deliver an email to [email protected].
2. The sending server queries _mta-sts.example.com for the MTA-STS DNS record.
3. The DNS TXT record is found, containing v=STSv1; id=2021090100.
4. The sending server fetches the policy from https://mta-sts.example.com/.well-known/mta-sts.txt.
5. The policy specifies that the connection should use enforce mode and lists mail.example.com as the valid MX server.
6. The sending server attempts to negotiate a TLS connection with mail.example.com.
7. If the TLS connection is successful and the certificate is valid, the email is delivered securely. If not, the email is not delivered (if in enforce mode).

Long DNS Records​

Like other DNS-based security protocols (e.g., SPF, DKIM), MTA-STS records may become long, especially if multiple parameters are included. However, DNS TXT records can be split across multiple strings, as per DNS standards, allowing for flexibility in configuration.

Example of a Long DNS Record​

_mta-sts.example.com. IN TXT "v=STSv1; id=2021090100; other-configurations"
                      "additional-strings-can-go-here"

Multiple strings in a DNS record are concatenated together when used.

Troubleshooting​

• Policy Not Found: If the policy file cannot be found at the specified HTTPS URL, the sending MTA will not enforce MTA-STS.
• Invalid Certificates: If the TLS certificates for the receiving domain's mail servers are invalid or expired, email delivery will fail if the policy is in enforce mode.
• MX Record Mismatch: Ensure that the MX servers listed in the MTA-STS policy match those configured in the DNS MX records. A mismatch could result in delivery failures.

Common Errors and Solutions​

Benefits of MTA-STS​

• Prevents Downgrade Attacks: Ensures emails are only delivered over TLS and mitigates potential downgrade attacks where the encryption is stripped.
• Strengthens Email Security: Improves the security of emails in transit by enforcing encryption.
• Compatibility with Other Standards: MTA-STS complements other email authentication protocols such as SPF, DKIM, and DMARC, offering an additional layer of security.

Drawbacks​

• Not Universally Supported: Some email servers do not yet support MTA-STS, meaning its enforcement may be limited in some cases.
• Complex Configuration: Setting up and maintaining MTA-STS policies, along with valid certificates and DNS records, requires careful configuration and ongoing monitoring.

Overview​

DMARC (Domain-based Message Authentication, Reporting & Conformance) is an email authentication protocol that builds on two other email standards, SPF (Sender Policy Framework) and DKIM (DomainKeys Identified Mail). DMARC adds a reporting mechanism, allowing domain owners to protect their domain from unauthorized use (email spoofing) and to receive feedback about authentication results from email receivers.

Key Functions of DMARC:​

1. Authentication: Validates that both SPF and DKIM are configured correctly and that their alignment is consistent with the "From" domain.
2. Reporting: Provides domain owners with visibility into emails sent on their behalf, helping to detect misuse or attacks.
3. Policy Enforcement: Enables domain owners to specify what to do with unauthenticated emails (none, quarantine, or reject).

DMARC Workflow​

1. Receiving System Queries DNS for DMARC Record:
   • When an email is received, the mail server first queries the domain's DNS (from RFC5322.From or Header From domain) for the DMARC TXT record to check whether the domain has an active DMARC policy.
2. SPF and DKIM Validation:
   • If a DMARC policy is found, the receiver evaluates the SPF and DKIM records:
     • SPF verifies that the sending server's IP address is authorized to send emails on behalf of the domain.
     • DKIM checks if the message has a valid digital signature and whether that signature aligns with the domain in the email header.
3. Alignment Check (RFC5321.From and RFC5322.From):
   • DMARC ensures that the RFC5321.MailFrom (Envelope From) and RFC5322.From (Header From) fields are aligned or match.
   • The RFC5321.MailFrom is used during the email transport phase, while the RFC5322.From is the address displayed to the recipient in the email client.
   • DMARC Alignment means that either SPF or DKIM has validated and the domain in those records matches the "From" address domain seen by the recipient.
4. Policy Enforcement:
   • At least one of the SPF or DKIM checks must pass for DMARC to validate successfully.
   • If both checks fail, the DMARC policy (p tag) determines how the receiving system handles the message.

DMARC DNS Record Details​

The DMARC record is a TXT record in DNS under the subdomain _dmarc. The basic structure of a DMARC record includes mandatory tags and optional tags, each serving a specific function.

Name​

_dmarc.[domain].[topdomain]

Example Value​

v=DMARC1; p=reject; fo=1; rua=mailto:[email protected]; ruf=mailto:[email protected]; rf=afrf; pct=100

Mandatory Tags​

Optional Tags​

Additional Details​

DMARC Aggregate Reports​

Aggregate reports provide information about how email flows are being authenticated, showing which emails passed or failed SPF, DKIM, and DMARC checks. These reports help domain owners monitor misuse, such as spoofing attempts. They are sent in XML format and include details like the volume of email from a specific sender and the authentication results.

DMARC Forensic Reports​

Forensic reports, on the other hand, are more granular and focus on specific failed messages. These reports can include headers of failed emails and give domain owners insight into why specific messages are not passing authentication. However, forensic reports may pose privacy concerns since they contain more detailed information about individual emails.

DMARC Policy Gradual Implementation (pct)​

The pct tag allows domain owners to gradually roll out their DMARC policies. For instance, starting with pct=10 applies the policy to only 10% of the domain's emails. This method is beneficial for organizations that want to monitor the effect of their DMARC policy without potentially impacting a large volume of legitimate mail.

SPF & DKIM Alignment Explained​

• SPF Alignment: For DMARC to pass, the domain in the Return-Path (envelope sender) used for SPF must match the domain in the From header. If relaxed alignment is used, subdomains are allowed to pass.
• DKIM Alignment: The domain used in the DKIM signature (d= tag) must match the domain in the From header. With strict alignment, the match must be exact, but with relaxed alignment, subdomains are allowed.

DMARC Failures and Considerations​

When DMARC fails (meaning neither SPF nor DKIM align and pass), the recipient's mail server consults the DMARC p= policy (none, quarantine, or reject) to determine how to handle the message. Quarantine typically sends it to spam, and reject results in outright blocking.

Overview​

ARC (Authenticated Received Chain) is an email authentication system designed to address issues that arise when email is forwarded. While SPF and DKIM validate the origin of an email, forwarding can break these authentication mechanisms, causing the email to fail checks when it reaches the final destination. ARC provides a solution by allowing each entity that handles the email (such as forwarders) to preserve the authentication results from earlier checks. This ensures that the final recipient can trace and verify the original authentication status of the message.

Workflow​

1. Sending System: The original sender sends an email that undergoes standard email authentication checks like SPF, DKIM, or DMARC.
2. Forwarding System: When the message passes through an intermediate mail server (e.g., a mailing list or forwarder), this system may break SPF/DKIM validation by modifying headers or changing the IP address.
   • The forwarding system applies ARC headers, which contain a signed record of the authentication results from the previous mail server.
3. Final Recipient's Mail Server:
   • When the message reaches its final destination, the recipient's mail server can verify the ARC chain, which contains the results of earlier SPF/DKIM checks, even if the forwarding process would have otherwise caused them to fail.
   • This allows the recipient's mail server to make an informed decision based on the complete history of the email's authentication.

Pros​

• Preserves Authentication: ARC allows authentication results to be preserved when an email is forwarded, preventing the message from failing SPF or DKIM checks due to legitimate forwarding.
• Improves DMARC Reporting: ARC works in tandem with DMARC to ensure that forwarded messages maintain their authenticity, enhancing DMARC's effectiveness.
• Email Traceability: By including a chain of authenticated entities, ARC provides transparency about the path the email took, helping the final recipient trust or reject the message based on a full record of its journey.

Cons​

• Complexity: ARC introduces additional complexity in the email authentication process. It requires all intermediate servers to properly implement ARC for it to function effectively.
• Limited Adoption: Although ARC solves forwarding issues, it is not yet widely adopted across all email service providers, meaning it might not always be effective.
• Trusting Intermediate Servers: ARC requires that recipients trust the integrity of intermediate servers. If a malicious server in the chain modifies the ARC headers, the entire chain could be compromised.

Details​

ARC Headers​

ARC works by adding three new headers to the email at each hop (forwarding server). These headers are signed and must be validated by the next hop and the final recipient.

ARC-Authentication-Results (AAR)​

This header records the results of the email authentication checks (such as SPF, DKIM, and DMARC) as performed by the intermediate mail server.

Example:

ARC-Authentication-Results: i=1; spf=pass smtp.mailfrom=example.com; dkim=pass header.d=example.com

ARC-Message-Signature (AMS)​

The ARC-Message-Signature header contains a cryptographic signature of the message, which allows the recipient to verify that the email was not altered between hops.

Example:

ARC-Message-Signature: i=1; a=rsa-sha256; d=forwarder.com; s=arcselector; bh=Y9PmG9RRk67sd9ZJ5sdXfX6uMSdshe5hTr==; b=Y5Usduf9sdsfoN9SdoffGtdfuh9asdfa+==

ARC-Seal (AS)​

The ARC-Seal header contains a cryptographic signature that ensures the integrity of the ARC headers added by each server. It acts as a seal that covers the entire ARC chain, preventing unauthorized modifications to the headers.

Example:

ARC-Seal: i=1; a=rsa-sha256; d=forwarder.com; s=arcselector; t=1613144111; cv=pass; b=Q9GsfT9f8PsffTFsf8hsfnsf8aTT==

Example of ARC Headers​

When an email is forwarded, ARC headers are added by each forwarding entity. Here's an example of how ARC headers might look after an email has been forwarded twice:

First Forwarder:

ARC-Authentication-Results: i=1; spf=pass smtp.mailfrom=example.com; dkim=pass header.d=example.com ARC-Message-Signature: i=1; a=rsa-sha256; d=forwarder1.com; s=selector1; bh=abc123; b=signature1 ARC-Seal: i=1; a=rsa-sha256; d=forwarder1.com; s=selector1; t=1613144111; cv=none; b=seal1

Second Forwarder:

ARC-Authentication-Results: i=2; spf=pass smtp.mailfrom=example.com; dkim=pass header.d=example.com ARC-Message-Signature: i=2; a=rsa-sha256; d=forwarder2.com; s=selector2; bh=def456; b=signature2 ARC-Seal: i=2; a=rsa-sha256; d=forwarder2.com; s=selector2; t=1613144211; cv=pass; b=seal2

How ARC Works with SPF, DKIM, and DMARC​

ARC does not replace SPF, DKIM, or DMARC; instead, it complements them. ARC provides a mechanism to preserve authentication results as an email passes through multiple servers, which can be helpful when DMARC would otherwise fail due to changes made by intermediate servers.

1. SPF: ARC ensures that SPF results are passed along, even if the forwarding server changes the IP address or SMTP envelope, which would otherwise cause SPF to fail.
2. DKIM: ARC preserves DKIM signatures, even if the email is modified in transit.
3. DMARC: ARC works with DMARC to ensure that legitimate forwarded messages aren't rejected due to SPF or DKIM failures, maintaining the trust chain.

Overview​

DKIM (DomainKeys Identified Mail) is an email authentication method that allows an organization to claim responsibility for a message by affixing a digital signature to it. The recipient's email server can then verify that the signature matches the message and that it was sent by an authorized sender, helping ensure the email has not been altered during transit. DKIM's goal is to prevent email spoofing and ensure message integrity.

Workflow​

1. The sending system takes specific parts of the email (typically the headers and sometimes the body) and generates a cryptographic hash, which represents the email content.
2. This hash is encrypted using the domain's private key and appended as the DKIM signature to the email's headers.
3. The DKIM signature contains metadata, such as which header fields were included in the hash and a reference to the DKIM DNS record for verification.
4. When the email arrives at the recipient's system, the receiving mail server:
   • Extracts the DKIM signature from the headers.
   • Looks up the DKIM public key in the DNS using the domain and selector specified in the signature.
   • Decrypts the signature with the public key, retrieving the original hash.
   • Recomputes the hash using the received email's header and body.
   • Compares the two hashes. If they match, the email passes DKIM validation, confirming that it wasn't altered in transit and that it was authorized by the signing domain.

Pros​

• Email Authenticity: DKIM confirms that the email was sent from a domain that has authorized the sender, enhancing trust.
• Message Integrity: DKIM ensures that the email's content (headers and optionally the body) hasn't been modified after it was signed by the sending server.
• Widely Supported: DKIM is widely adopted and supported by major email providers, including Google, Microsoft, and Yahoo.
• Plays well with DMARC: When used in conjunction with DMARC, DKIM helps establish a domain's email authentication policy, ensuring that spoofed messages are more likely to be rejected.

Cons​

• Does not protect "MAIL FROM": DKIM does not authenticate the "MAIL FROM" (envelope sender) address. Spoofers can still manipulate this value to mislead recipients.
• Forwarding Issues: Forwarded messages may cause DKIM verification to fail. This occurs because forwarding servers often modify parts of the email, such as headers or the body, that were included in the DKIM signature.
• Key Management: Administrators must manage DKIM keys securely, rotating them periodically to prevent compromise.
• Requires DNS: DKIM relies heavily on DNS infrastructure for the public key, meaning disruptions in DNS can lead to authentication issues.

Details​

DNS Record​

The DKIM DNS record is a TXT record published by the domain owner in the DNS zone file. This record contains the public key that receiving mail servers use to verify the DKIM signature.

DNS Record Name​

[selector]._domainkey.[domain].[topdomain]

• Selector: A label (usually a short string) defined by the domain owner, used to differentiate multiple DKIM keys for the same domain.
• Domain: The sender's domain (e.g., example.com).
• Top Domain: The top-level domain (e.g., .com, .org).

Example Value​

v=DKIM1; p=[yourPublicKey]

Mandatory Tags​

Recommended Tags​

Optional Tags​

Long DNS Records​

When the DKIM public key is too long (which is common for 2048-bit keys), the DNS TXT record may exceed the 255-character limit. To solve this, the key can be split into multiple quoted strings in a single DNS TXT record.

Example:

"p=string_part1"
"string_part2"
"string_part3"

DKIM Signature​

The DKIM signature is added as an email header when the message is sent. This signature contains metadata about the signature process and the cryptographic signature itself.

Example Value​

DKIM-Signature: v=1; a=rsa-sha256; d=example.net; s=brisbane; c=relaxed/simple; q=dns/txt; l=1234; t=1117574938; x=1118006938; h=from:to:subject; bh=MTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTI=; b=dzdVyOfAKCdLXdJOc9G2q8LoXSlEniSbav+yuU4zGeeruD00lszZVoG4ZHRNiYzR

Tags in the DKIM Signature​

Canonicalization Algorithms​

The canonicalization process normalizes the email's header and body content before hashing and signing, ensuring that insignificant changes (like extra whitespace) don't break DKIM verification. The two common methods are:

1. relaxed: Reduces whitespace and normalizes header field names, making the signature more resilient to minor changes.
2. simple: Requires an exact match of the header and body, making it more prone to failure if even minor modifications occur (e.g., forwarding or adding extra headers).

Interplay with SPF and DMARC​

While DKIM verifies the integrity and authenticity of an email, it does not authenticate the sending server's IP address, as SPF (Sender Policy Framework) does. DMARC (Domain-based Message Authentication, Reporting & Conformance) combines DKIM and SPF, allowing domain owners to set policies for how emails that fail authentication checks should be handled (e.g., reject, quarantine, or accept).

Overview​

The Sender Policy Framework (SPF) is an email authentication method designed to detect and block email spoofing by verifying the IP address of the sender. SPF works by using DNS records to define which IP addresses are allowed to send emails on behalf of a domain. When an email is received, the recipient's mail server checks the SPF record to confirm that the message comes from an authorized server, helping prevent spammers from forging the domain of the sender.

Workflow​

1. The receiving system looks at the Return-Path/Envelope From (also known as "MAIL FROM") address in the SMTP header.
2. It then queries DNS to fetch the SPF record associated with the domain in this "Return-Path."
3. The server checks if the sending IP address matches the authorized IP addresses defined in the SPF record.
4. SPF allows the domain to define its authorized mail servers using mechanisms such as A, MX, Include, IPv4, and IPv6 records. These records can be recursively resolved for additional IP addresses.
5. Based on the results of the SPF validation, the recipient server determines the authenticity of the email and applies a decision: pass, neutral, softfail, or fail.

Pros​

• Domain Protection: SPF ensures that only authorized IP addresses can send email on behalf of a domain, reducing the risk of unauthorized domain usage.
• Visibility: It provides transparency to email receivers, showing whether the sending mail server is legitimate and recognized by the domain owner.

Cons​

• Maintenance: Keeping SPF records up to date is a challenge, especially when domains use multiple email service providers (ESPs) or when email-sending infrastructure changes over time. A lack of central visibility across departments and providers makes it difficult to maintain a correct and complete SPF record.
• Limited Rejection Capability: A failed SPF check doesn't always result in message rejection. Email providers weigh SPF results alongside other factors like DKIM (DomainKeys Identified Mail) and DMARC (Domain-based Message Authentication, Reporting & Conformance) before deciding to accept or block an email.
• Forwarding Issues: SPF checks can break when an email is forwarded. Since the forwarding server typically doesn't match the original sender's SPF, the forwarded email can fail SPF validation unless the domain implements other safeguards like DMARC with DKIM.
• Display Name Spoofing: SPF only authenticates the MAIL FROM domain (Return-Path), which is often not visible to the recipient. Cybercriminals can still spoof the "From" header, a visible field for the user, and SPF won't protect against this type of impersonation.

Details​

DNS Record Format​

An SPF record is a DNS TXT record that defines which IP addresses or hosts are allowed to send email for a domain.

DNS Record Name:

• @.[domain].[topdomain]
• *.[domain].[topdomain]
• [domain].[topdomain]

Example SPF Record:

v=spf1 ip4:203.0.113.2 a.example.com include.protection.outlook.com ~all

Here's a breakdown:

• v=spf1: Declares the version of SPF.
• ip4:203.0.113.2: Authorizes an IPv4 address to send mail.
• a:mail.example.com: Authorizes the IP address of mail.example.com.
• include:spf.protection.outlook.com: Allows email sent through Outlook's infrastructure.
• ~all: Softfail; all other servers not specified in the record are likely unauthorized but not strictly blocked.

Mandatory Tags​

Optional Tags​

Qualifiers​

Additional Considerations​

1. SPF Record Length: DNS TXT records are limited to 255 characters, and the entire SPF record cannot exceed 512 characters in a single DNS query. This can lead to problems if too many mechanisms (like include or a) are used in the record. If the record becomes too long, it needs to be split across multiple records, or optimized by consolidating mechanisms.
2. DNS Lookups: SPF records should not exceed 10 DNS lookups. Each time the SPF record references a domain with a, mx, or include mechanisms, it requires an additional DNS lookup. Exceeding this limit can result in SPF records that fail to authenticate, which could lead to undelivered or flagged emails.
3. SPF, DKIM, and DMARC Interplay: While SPF verifies that an email was sent from an authorized server, it does not authenticate the content of the email or the integrity of the headers. DKIM helps address this by attaching a digital signature to the email, ensuring that the content has not been altered. Together, SPF and DKIM can be combined under DMARC policies to provide stronger email authentication, allowing domain owners to control how failed SPF and DKIM checks are handled.

Conclusion​

SPF plays a critical role in the fight against email spoofing, but it is not a standalone solution. When used in conjunction with DKIM and DMARC, it becomes a powerful tool to prevent fraudulent emails from reaching users. However, maintaining accurate and up-to-date SPF records is crucial, especially for businesses that leverage multiple service providers or frequently change their infrastructure. Ensuring compliance with DNS lookup limits and SPF's compatibility with email forwarding is key to its effective use.