Frequently Asked Questions (FAQ)

We check for new reports every hour. However, please note that most email providers typically send their reports once a day.

DMARC (Domain-based Message Authentication, Reporting, and Conformance) is an email authentication protocol that helps protect your domain from email spoofing. It allows domain owners to specify how unauthenticated emails should be handled and provides a way to receive reports about email sent from their domain. By implementing DMARC, you can improve your domain's email security and prevent phishing attacks.

To set up a DMARC record, you need to add a TXT record to your domain's DNS settings. The TXT record should include the DMARC policy you want to enforce, such as 'none', 'quarantine', or 'reject'. You should also specify an email address where you want to receive DMARC reports. Here is an example of a DMARC record: v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com

SPF, DKIM, and DMARC are all email authentication protocols that work together to protect your domain from email spoofing. SPF specifies which mail servers are allowed to send email on behalf of your domain. DKIM uses cryptographic authentication to verify that an email was sent by an authorized mail server and hasn't been altered in transit. DMARC builds on SPF and DKIM, allowing domain owners to specify how unauthenticated emails should be handled and providing a way to receive reports about email sent from their domain.

Without a DMARC policy, your domain is vulnerable to email spoofing, where malicious actors can send emails pretending to be from your domain. This can lead to phishing attacks and damage your domain's reputation. By implementing a DMARC policy, you can improve your domain's email security and prevent these issues.

You can monitor the effectiveness of your DMARC policy by reviewing the DMARC reports you receive. These reports provide information about emails sent from your domain and how they were handled by receiving mail servers. By analyzing these reports, you can identify and address any issues with your email authentication setup and ensure that your DMARC policy is working as intended.

SPF Record Structure:

Start with v=spf1: This indicates that the record is an SPF version 1 record.

Mechanisms:

These define the servers that are authorized to send emails for the domain. Common mechanisms include:

• all: Matches any IP address. It is usually used at the end of the SPF record to specify what to do if no previous mechanisms match.
• ip4: Matches an IPv4 address or range of IPv4 addresses.
• ip6: Matches an IPv6 address or range of IPv6 addresses.
• a: Matches the IP addresses of the domain's A or AAAA records.
• mx: Matches the IP addresses of the domain's MX records.
• ptr: Matches the IP addresses of PTR records.
• exists: Performs an existence check.
• include: Includes the SPF record of another domain.

Qualifiers:

• + (Pass): The default qualifier if none is specified.
• - (Fail): If the mechanism matches, the email should be rejected.
• ~ (SoftFail): If the mechanism matches, the email should be accepted but marked as suspicious.
• ? (Neutral): No specific action if the mechanism matches.

Order of Mechanisms:

Mechanisms are evaluated from left to right, and the first match determines the result.

Example SPF Record:

v=spf1 ip4:192.168.0.1 ip4:192.168.0.2 include:example.com -all

This record specifies that emails can be sent from 192.168.0.1, 192.168.0.2, or any IP address listed in the SPF record of example.com. All other IP addresses should be rejected.

Best Practices:

• Limit the Number of DNS Lookups: An SPF check is limited to 10 DNS lookups. This includes mechanisms like include, a, mx, ptr, and exists.
• Use -all Carefully: Using -all means that any sender not explicitly listed will fail SPF. This can be strict and should be used only when you are confident that all legitimate senders are covered.
• Keep it Simple: Avoid overly complex SPF records to minimize errors and ensure easier management.
• Monitor and Adjust: Regularly review your SPF records and adjust them as necessary to ensure they continue to reflect your sending infrastructure.

SPF Record Testing:

Use tools to test your SPF records to ensure they are correctly configured and do not exceed the 10 DNS lookup limit. Tools like our DMARCsimple testing tool can be helpful for this purpose.

DKIM (DomainKeys Identified Mail) is an email authentication method that uses cryptographic signatures to verify that an email was sent by an authorized mail server and hasn't been altered in transit. It helps protect your domain from email spoofing and phishing attacks by ensuring the integrity and authenticity of your emails.

Yes, it's possible to have multiple DKIM records for a domain, especially if you utilize multiple email service providers. Each provider will generate a unique DKIM signature, which needs to be added to your DNS settings to ensure proper authentication for emails sent through each provider.

To set up a DKIM record, you need to generate a pair of cryptographic keys: a private key and a public key. The private key is used by your email server to sign outgoing emails, while the public key is published in your domain's DNS settings as a TXT record. Here is an example of a DKIM record: v=DKIM1; k=rsa; p=publicKey

A DKIM signature includes several components:

• d=: The domain of the signing entity.
• s=: The selector, which specifies the location of the public key in DNS.
• h=: A list of header fields included in the signature.
• bh=: The body hash, a hash of the email body.
• b=: The signature itself, a base64-encoded cryptographic signature.

The DKIM selector is used to specify which DKIM public key should be used to verify the signature. It is included in the DKIM-Signature header as 's=selector'. The receiving mail server uses this selector to locate the public key in DNS.

Example DKIM Record:

v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDCVVOziY5S3sdnT/6BSsy6LMF9pTjLfGTkqLHZU9JwzRPVGJSBz+Yj3RmD4zF7ZuaxU6zURTzLePE/0PaxJ53ykf/P9c4pZmQy9PhXJlLP+19PcmCqU+MyEATZ1+7PU7DpZjbd4qKtbdjfhwRm07RE+MLlFScaQbtrN0sX+1Rf9ywIDAQAB

This record specifies the public key used to verify DKIM signatures for the domain.

You can monitor the effectiveness of your DKIM setup by reviewing the DKIM results in your DMARC reports. These reports provide information about emails sent from your domain and how they were handled by receiving mail servers. By analyzing these reports, you can identify and address any issues with your DKIM implementation.

Best Practices:

• Use Strong Keys: Use at least 1024-bit keys, but preferably 2048-bit keys for better security.
• Rotate Keys Regularly: Regularly rotate your DKIM keys to reduce the risk of key compromise.
• Monitor and Adjust: Regularly review your DKIM implementation and adjust it as necessary to ensure it continues to protect your domain effectively.
• Combine with SPF and DMARC: Use DKIM in conjunction with SPF and DMARC to provide a comprehensive email authentication strategy.

DKIM Record Testing:

Use tools to test your DKIM records to ensure they are correctly configured and can be properly validated by receiving mail servers. Tools like our DMARCsimple testing tool can be helpful for this purpose.

A DMARC Summary Report, also known as an Aggregate Report, provides an overview of email authentication results across an entire domain. It is generated by email receivers (like Gmail, Yahoo, etc.) and sent to the domain owner on a daily basis. These reports include data on the volume of emails that passed or failed DMARC, SPF, and DKIM checks, helping domain owners monitor and understand their email authentication status.

DMARC Summary Reports include:

• The sending source’s IP address.
• The domain that sent the email.
• The number of emails sent.
• Authentication results for SPF and DKIM.
• Actions taken by the receiver (e.g., reject, quarantine, or none).

A DMARC Forensic Report, also known as Failure Report, provides detailed information about specific email messages that fail DMARC authentication. These reports are generated in real-time and contain granular details about each failed email, enabling domain owners to investigate potential abuse or misconfigurations immediately.

DMARC Forensic Reports include:

• The full email headers.
• Information about why the email failed authentication.
• The sending IP address.
• The subject of the email.
• The recipient’s email address.

DMARC Summary Reports are typically generated and sent daily by email receivers. Some providers may offer the option to adjust the reporting frequency, but daily reports are the most common.

DMARC Forensic Reports are generated in real-time, as soon as an email fails DMARC authentication. These reports are sent immediately to the domain owner for quick action.

Both reports serve important purposes:

• Summary Reports: Useful for getting a high-level view of your email authentication landscape and trends over time. Ideal for regular monitoring and strategic adjustments.
• Forensic Reports: Crucial for detailed investigations of specific failures. Useful for immediate response to potential threats or misconfigurations.

Yes, you can configure your DMARC policy to request both types of reports. This dual approach allows for comprehensive monitoring and in-depth investigation capabilities.

To receive DMARC Summary and Forensic Reports, you need to include the appropriate reporting URIs (RUA for Aggregate Reports and RUF for Forensic Reports) in your DMARC DNS record. For example:

v=DMARC1; p=none; rua=mailto:aggregate@example.com; ruf=mailto:forensic@example.com; fo=1;

There are several reasons you might not receive DMARC Forensic Reports:

• Some email receivers may not support or generate forensic reports.
• The volume of emails failing DMARC might be low.
• Your email address for receiving forensic reports may have filtering issues or be incorrectly configured.

Yes, DMARC Forensic Reports can contain sensitive information, such as the subject and recipient's email address. It is important to handle these reports securely and ensure they are sent to a trusted email address.

• Summary Reports: Analyze trends, identify common sources of authentication failures, and adjust your SPF/DKIM configurations or DMARC policy accordingly.
• Forensic Reports: Investigate specific incidents of failure, determine if they are due to misconfigurations or malicious activity, and take corrective actions quickly.

If you are not receiving your DMARC Summary or Forensic Reports, there could be several reasons. Here are some common issues and solutions:

1. Incorrect DMARC Record Configuration

Issue: Your DMARC DNS record might not be correctly configured to request reports.

Solution: Ensure that your DMARC record includes the correct reporting URIs. For example:

v=DMARC1; p=none; rua=mailto:aggregate@example.com; ruf=mailto:forensic@example.com; fo=1;

2. Email Receiver Limitations

Issue: Some email receivers may not support or may limit the generation and sending of DMARC reports.

Solution: Check the documentation or contact the support teams of the major email receivers (like Gmail, Yahoo, etc.) to understand their reporting capabilities and limitations. Ensure that the email receivers you are dealing with are capable of sending the reports.

3. Low Email Volume

Issue: If your domain sends a low volume of emails, there might not be enough data to generate daily DMARC reports.

Solution: Monitor your email sending volume and ensure that there is sufficient email traffic to trigger report generation. If your email volume is inherently low, consider reviewing reports over a longer period to gather meaningful insights.

4. Email Filtering and Spam Issues

Issue: Reports might be getting filtered out or marked as spam by your email system.

Solution: Whitelist the email addresses and domains that send DMARC reports. Check your spam or junk folders regularly to ensure that the reports are not being mistakenly filtered out.

5. Report Delivery Delays

Issue: There might be delays in the generation and delivery of DMARC reports due to server processing times or network issues.

Solution: Allow some time for the reports to be delivered, especially during peak email traffic periods. If delays persist, contact your email service provider to investigate potential issues.

6. Misconfigured Email Address

Issue: The email address specified for receiving DMARC reports might be incorrect or inactive.

Solution: Double-check the email address specified in the rua and ruf tags of your DMARC record. Ensure that the mailbox is active, correctly set up, and able to receive external emails.

7. Lack of Forensic Report Generation

Issue: Forensic reports are not generated as frequently as summary reports and are dependent on email failures.

Solution: Verify if there have been any authentication failures that would trigger forensic reports. If your domain’s email authentication is well-configured and emails are passing DMARC, forensic reports may naturally be minimal or absent.

8. Monitor and Test

Issue: You might not have a clear monitoring or testing process in place.

Solution: Regularly monitor your DMARC report receiving process. Use tools and services to test and validate your DMARC, SPF, and DKIM configurations. Conduct periodic tests to ensure that reports are being generated and received as expected.