Skip to main content

8 posts tagged with "Email security"

View All Tags

Understanding How BIMI Enhances Email Trust and Brand Visibility

· 6 min read
Hannes Palmquist
Senior Consultant Cloud

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

TagDescription
vSpecifies the BIMI version. The current version is BIMI1.
lSpecifies the URL where the brand's SVG logo is hosted. The format is l=[URL], and the URL must point to a .SVG file that complies with the BIMI SVG specifications.

Optional Tags

TagDescription
aSpecifies the URL for an Authority Evidence Document, such as a Verified Mark Certificate (VMC). This tag is optional and adds an extra layer of verification, ensuring that the logo has been certified by a recognized authority.

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.

Understanding How DANE Enhances TLS Security with DNSSEC

· 7 min read
Hannes Palmquist
Senior Consultant Cloud

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:

FieldDescription
UsageSpecifies how the certificate is to be used. It indicates whether the certificate must match a specific certificate or just be part of a valid certification path.
SelectorDefines what part of the certificate should be checked (e.g., full certificate or just the public key).
Matching TypeDescribes how the selected data should be matched (e.g., exact match, SHA-256 hash).
Certificate Association DataThe actual data to match (either a hash or the full certificate/public key).

Usage Field Values

ValueMeaning
0CA Constraint: The certificate must be issued by a specific CA listed in the TLSA record.
1Service Certificate Constraint: The server must use a specific certificate directly listed in the TLSA record.
2Trust Anchor Assertion: The server's certificate must chain to a specific trust anchor, not necessarily a public CA.
3Domain-Issued Certificate: The server uses a certificate issued directly by the domain owner. No public CA is needed.

Selector Field Values

ValueMeaning
0Full certificate (X.509)
1Subject Public Key (only the public key is used for verification)

Matching Type Field Values

ValueMeaning
0Exact match of the raw certificate or public key.
1SHA-256 hash of the certificate or public key.
2SHA-512 hash of the certificate or public key.

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.

Understanding How TLS-RPT Enhances Email Security Through Reporting

· 5 min read
Hannes Palmquist
Senior Consultant Cloud

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

TagDescription
vSpecifies the version of the TLS-RPT protocol. The current version is TLSRPTv1.
ruaSpecifies the destination email address for aggregate reports of TLS failures. The format is rua=mailto:[address].

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.

Understanding How MTA-STS Enhances Email Security

· 7 min read
Hannes Palmquist
Senior Consultant Cloud

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"

FieldDescription
v=The version of the MTA-STS protocol. This should always be set to STSv1.
id=A unique identifier for the policy. This can be a timestamp or version number to track updates.

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
FieldDescription
version:The version of the MTA-STS protocol. Must be STSv1.
mode:Specifies the mode of the policy. Can be enforce, testing, none. In enforce mode, emails will only be delivered if TLS is properly negotiated.
mx:Lists the MX servers that are allowed to receive email for the domain.
max_age:Specifies how long the policy is valid, in seconds. After this period, the sending MTA will query the DNS again to fetch the latest policy.

Policy Modes

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

ModeDescription
enforceStrict mode that requires TLS for all connections. Emails will only be delivered if the TLS connection is successfully negotiated.
testingEmails will be delivered even if the TLS connection fails, but logs will record whether TLS was successfully used. This is useful for testing MTA-STS without risking message delivery failures.
noneDisables MTA-STS enforcement but allows the policy file to remain in place for future use.

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

ErrorCauseSolution
Policy Fetch FailureIncorrect HTTPS URL or missing policy file.Verify that the policy is correctly hosted athttps://mta-sts.example.com/.well-known/mta-sts.txt.
TLS Negotiation FailureInvalid or missing TLS certificates on the MX servers.Ensure valid certificates are in place and that the MX servers are correctly configured to support TLS.
MX Record MismatchThe MX servers listed in the MTA-STS policy do not match DNS records.Ensure that the MX records in DNS match those listed in the policy.

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.

Understanding How DMARC Enhances Email Security Through Authentication and Reporting

· 6 min read
Hannes Palmquist
Senior Consultant Cloud

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 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

TagDescription
vSpecifies the version of DMARC. This is always v=DMARC1.
pDefines the policy for handling messages that fail DMARC checks. Possible values include:
p=none: No action; monitoring only.
p=quarantine: Treat mail that fails as suspicious (e.g., move to spam).
p=reject: Reject mail that fails DMARC checks during the SMTP transaction.

Optional Tags

TagDescription
spSubdomain Policy: Specifies the policy for subdomains. This is often used when subdomains follow a different policy from the top-level domain. If not set, subdomains inherit the policy from the p tag.
Example: sp=reject to reject emails from subdomains that fail DMARC.
ruaAggregate Reports (RUA): Specifies the address where aggregate reports (summary of authentication results) should be sent. The format is mailto:[email protected]. Aggregate reports give insights into how often mail is passing/failing DMARC.
rufForensic Reports (RUF): Specifies the address where forensic (detailed) failure reports should be sent. These reports are more detailed and sent when individual emails fail authentication. Format: mailto:[email protected].
adkimDKIM Alignment Mode: Specifies how strict or relaxed the DKIM alignment should be.
adkim=r: Relaxed (default). The domain in the DKIM signature can be a subdomain of the "From" domain.
adkim=s: Strict. The DKIM signature domain must exactly match the "From" domain.
aspfSPF Alignment Mode: Similar to DKIM alignment, this dictates how closely the SPF domain must align with the "From" domain.
aspf=r: Relaxed (default). Subdomains are allowed to pass alignment.
aspf=s: Strict. The domain in the SPF must match exactly with the "From" domain.
rfReport Format: Specifies the format for failure reports. The default is afrf (Authentication Failure Reporting Format). This is the standard format used for DMARC reports.
riReport Interval: Specifies the interval (in seconds) between aggregate reports. The default is 86,400 seconds (24 hours). Receivers may send reports more frequently based on their settings, but this is only a guideline.
pctPercentage: Specifies the percentage of messages to which the DMARC policy is applied. For instance, setting pct=50 applies the policy to only half of the emails. This allows gradual implementation.
foFailure Reporting Options: Determines the conditions under which failure reports are sent. Possible values include:
fo=0: Default. Send reports if both DKIM and SPF fail.
fo=1: Send a report if either DKIM or SPF fails.
fo=d: Send a report if DKIM fails, regardless of alignment.
fo=s: Send a report if SPF fails, regardless of alignment.

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.

Understanding How ARC (Authenticated Received Chain) Ensures Email Authentication Through Forwarding

· 6 min read
Hannes Palmquist
Senior Consultant Cloud

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

FieldDescription
i=The "instance" number, which represents the number of hops the email has gone through. Each forwarding system increments this value.
spf=The result of the SPF check (e.g., pass, fail, neutral).
dkim=The result of the DKIM check (e.g., pass, fail, none).
header.d=The domain name used in the DKIM signature.

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+==

FieldDescription
i=The instance number. It must match the instance in the other ARC headers.
a=The algorithm used for the digital signature (e.g., rsa-sha256).
d=The domain name of the forwarding entity that signs the message.
s=The selector used to identify the signing key in the DNS.
bh=The hash of the canonicalized body.
b=The actual cryptographic signature of the message.

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==

FieldDescription
i=The instance number, matching the instance in the other ARC headers.
a=The algorithm used for the seal (e.g., rsa-sha256).
d=The domain of the forwarding system signing the seal.
s=The selector identifying the signing key in the DNS.
t=The timestamp indicating when the seal was created.
cv=The result of validating the previous ARC chain (pass, fail).
b=The cryptographic signature of the seal, covering the ARC-Authentication-Results, ARC-Message-Signature, and ARC-Seal from the previous instance.

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.

Understanding How DomainKeys Identified Mail (DKIM) helps protect your organization

· 7 min read
Hannes Palmquist
Senior Consultant Cloud

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, which is often displayed in email clients. 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

TagDescription
vThe version of the DKIM record. This must be DKIM1 and should appear as the first tag.
pThe public key. This is the key used by receiving mail servers to validate the DKIM signature.
TagDescription
tTesting Mode: t=y indicates that the domain is testing DKIM. When testing is complete, this tag should be removed or changed to t=s to enforce DKIM signatures.
t=sStrict Matching: If the i= tag in the DKIM signature is used, this enforces that the "i=" domain must match the "d=" domain exactly, without allowing subdomains.

Optional Tags

TagDescription
gGranularity: Defines which local-part of an email address (before the @ sign) can use the key. A wildcard * allows all users in the domain to use the selector.
hHash Algorithms: Specifies which hash algorithms are acceptable (sha1, sha256). DKIM requires that both the sender and the verifier support sha256.
kKey Type: Specifies the key algorithm (default: RSA).
nNotes: For administrative use, this can contain a human-readable note for admins. It does not impact DKIM functionality.
sService Type: Defines the service type the record applies to (e.g., email). By default, this applies to all service types (*).

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

TagDescription
vDKIM version. It should always be v=1.
aSigning algorithm (e.g., rsa-sha256).
dDomain name of the signing entity (e.g., example.net).
sSelector. This links to the correct DKIM public key in the DNS record.
cCanonicalization algorithms for the header and body. These determine how the email is normalized before signing. Common values are relaxed/relaxed and relaxed/simple.
qQuery method (usually dns/txt to retrieve the public key).
lLength of the canonicalized body that was signed.
tTimestamp indicating when the signature was created.
xExpiry time after which the signature is no longer valid.
hA list of the email headers that were signed (e.g., from:to:subject:date).
bThe actual digital signature of the email, generated using the private key.
bhThe hash of the canonicalized body. This is used to verify that the body has not been altered.

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).

Understanding How Sender Policy Framework (SPF) provides Email Authentication

· 6 min read
Hannes Palmquist
Senior Consultant Cloud

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

TagDescription
vSPF version identifier, typically v=spf1.
-all or ~allThe -all indicates a hard fail (strict rejection), while ~all is a soft fail (mail is accepted but flagged).

Optional Tags

TagDescription
allA catch-all mechanism to define the default behavior if no other rule is matched.
ip4Specifies the authorized IPv4 address.
ip6Specifies the authorized IPv6 address.
aAuthorizes the IP address corresponding to an A (IPv4) record of a domain.
mxAuthorizes IP addresses listed in the domain's MX (Mail Exchange) records.
includeIncorporates another domain's SPF records into the current record. Used when a domain delegates email sending to a third-party service provider (e.g., Google or Microsoft).
ptrChecks if the sending IP's reverse DNS matches the domain name. (Rarely used due to performance issues and poor reliability. It's considered deprecated.)
existsEvaluates a complex DNS lookup to verify the sender's IP address. This is rarely used in SPF.

Qualifiers

QualifierDescription
+ (Pass)Explicit pass result, though this can be omitted since it's the default behavior. For example, +mx is the same as mx.
? (Neutral)Indicates that the result is neutral, treated as if there is no policy.
~ (Softfail)Marks the email as suspicious but does not reject it outright. Often used for debugging purposes. Messages that fail with a softfail are generally delivered but marked as suspect.
- (Fail)Hard fail, meaning the email should be rejected by the receiving server.

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.