People sometimes run into the "too many DNS lookups" error when rolling out SPF (Sender Policy Framework). It doesn't help that there is a lot of bad guidance on the Internet. This article describes how to fix this issue. Read the rest of this entry »
A common problem many people face when implementing DMARC for the first time is that they are not receiving aggregate XML reports (reports generated for delivery to the rua= tag) in their dmarcian account. These XML reports are the driving force of DMARC. Without them, it's very difficult to get an accurate picture of your domain's usage across the internet.
If you've created a dmarcian account, have published records but have not received data, don't fret! It is typically caused by one (or more) of these three things: Read the rest of this entry »
dmarcian tools are under constant development to make DMARC deployment faster and easier for everyone. This article describes how to best use the tools today. Read the rest of this entry »
Domain Groups allow dmarcian users to easily group together and manage related domains. Domain Groups are created using the Mission Control interface. Domain Groups are typically used to group together domains by: Read the rest of this entry »
To turn DMARC into something useful to people, dmarcian processes DMARC data using a big pile of rules. These rules identify sources of email, and dmarcian presents users with DMARC compliance information based on email source.
One identified source of email is called "SPF-Identified Servers", and dmarcian users are often curious as to how data ends up in this source. How and why this source works is explained below. Read the rest of this entry »
dmarcian maintains rules to classify DMARC data into 4 high level categories. Our categories are:
- DMARC Capable
- Non-compliant Sources
People sometimes write in and ask "what is the impact of a broken SPF record"?
The net effect of a broken SPF record is that receivers can't reliably use SPF to determine the legitimacy of the domain's email. *Some* receivers might ignore the broken parts of an SPF record and keep checking, but out of the box all SPF implementations will barf, and you'll be left with a record that is introducing uncertainty into email performance.
We've discovered an odd story related to SPF deployment. When delivering a lot of email, you need an SPF record just to get to the welcome mat. What happens is that new senders go through their pre-flight check list, start sending with working SPF records, and things operate in a nice steady state for a while.
Over time, the servers that are authorized using SPF earn enough good reputation so that senders get through the front door and into the content-based/user-engagement world. At any time, SPF records may get extended until they break or become inaccurate, but since the original set of authorized servers already has a good enough reputation, the inaccurate/broken SPF records do not cause too much trouble. This is how SPF has traditionally been used prior to DMARC. In this way, SPF might have been a "reputation bootstrapping tool".
Unfortunately, when SPF breaks, the newly authorized servers are left out in the cold. People then hire deliverability experts, build volume ramps, and chase symptoms as most of their email is doing OK. Worse is the resulting notion that email infrastructure is a heavy weight and cannot be replaced or upgraded without serious investment.
DMARC changes the above story in a very significant way. First is visibility — you can actually see what is going on and where SPF isn't performing like it should. Second is that SPF results now matter in terms of email content and identifier alignment. In sum, accurate SPF records are no longer a "reputation bootstrapping tool", but necessary for reliable email delivery.
If you publish an SPF record and use the "a" mechanism, but your domain doesn't actually have a "A" record in place, then you'll see this warning.
Here's a sample SPF record that contains the "a" mechanism (the "a" is in bold):
v=spf1 a include:_spf.google.com ~all
The "A" DNS record is how you use the DNS to associate an IP address with your domain. The "AAAA" DNS record (also called "quad-A") is used to associate an IPv6 address with your domain.
If you don't have an IP address associated with your domain, then you shouldn't use the "a" mechanism in your SPF records. This might be case if you're only using your domain for email.
Users sometimes ask What does "No DMARC reports received yet which confirm DKIM signing" mean?
dmarcian uses DMARC-XML data to detect the presence of DKIM signatures. There is no straight-forward way to query the internet for the presence of DKIM signatures, and so dmarcian relies on the contents of DMARC-XML reports to provide information on DKIM signatures.
Given the above, there are 4 reasons why you might see this message:
- DKIM hasn't been implemented with the domain's source(s) of email.
- DKIM hasn't been fully implemented. For example, Google Apps for Work requires a verification step before DKIM signing is fully enabled for a domain.
- dmarcian has not yet received a DMARC report containing DKIM information. Either no reports have been received for the domain, or reports may have been received only with regard to non-DKIM-verified email (ie, spam, abuse, or legitimate email that hasn't yet been DKIM signed).
- DMARC-XML data doesn't contain relevant DKIM signatures for the particular domain.
Regarding #1, you'll need to setup DKIM by allowing the source of email to on behalf of your domain. How this is implemented differs based on the capabilities of the email source. For example, Google Apps for Work requires you to copy a DKIM TXT record into your domain's hosting/DNS provider. In some cases (eg. GoDaddy) you will also need to click an additional "Save changes" button in order to confirm the new TXT record.
Regarding #2, after updating the hosting/DNS provider, make sure the source of email has accepted the changes (eg with Google Apps for Work, you'll need to click "Start Authentication").
Regarding #3, you will need to send at least one email from the domain to a DMARC-compliant receiver in order to ensure that a DMARC report will be generated. The generated report will contain DKIM verification data. A few of the most common DMARC-compliant receivers are Gmail, Yahoo, Microsoft, and AOL; sending an email to any legitimate email address provided by any of those will suffice. (The actual email recipient and the contents of the email are not important.)
Regarding #4, if the email domain under question is "EXAMPLE.ORG" and you're signing this domain with DKIM signatures of a different domain (eg "SAMPLE.NET"), dmarcian.com will emit the "No DMARC reports received yet which confirm DKIM signing" message. This is because there is no relation between EXAMPLE.ORG and SAMPLE.NET. So, although your email might be signed, the domain used in the signatures might not match your DMARC domain.