SPF, DKIM, DMARC: Her İmza Takipçisinin Sahip Olması Gerekenler
SPF, DKIM, DMARC: what every signature tracker needs in place
You configured your email signature tracker, added the pixel, and started sending. Then your emails land in spam, or worse, get silently rejected. The culprit is almost never the tracker itself — it is missing or misconfigured email authentication.
Email signature trackers rely on a tiny invisible image (a tracking pixel) embedded in your HTML signature. If your email fails SPF, DKIM, or DMARC checks, receiving servers treat your message as suspicious. The pixel never loads, your open rates drop to zero, and your deliverability tanks. Here is exactly what each protocol does, why it matters for signature tracking, and how to get it right.
Why email authentication directly affects your tracking pixel
Every time you send an email with a signature tracker, the receiving server checks whether the email is legitimate. It verifies the sender domain against the IP address that sent the message (SPF), checks a cryptographic signature (DKIM), and then applies the domain owner's policy (DMARC). If any of these checks fail, the email may be quarantined, rejected, or stripped of external content — including your tracking pixel.
The tracking pixel is an external resource hosted on your tracker's domain. If the email itself fails authentication, many mail servers (especially Gmail and Outlook) will refuse to load external images at all. This means your open tracking data becomes unreliable, even if the email technically arrives in the inbox.
The fix is not to change your tracker. The fix is to authenticate the domain you are sending from. No amount of pixel placement or retry logic can bypass a DMARC reject policy.
SPF: the first line of defence for your sending IP
Sender Policy Framework (SPF) tells receiving servers which IP addresses are authorised to send email on behalf of your domain. You publish an SPF record as a TXT record in your DNS. When an email arrives, the server checks the envelope sender domain (the Return-Path) against that record.
What happens when SPF is missing or wrong
If your SPF record does not include the IP of your email service provider (ESP) or your own mail server, the email fails SPF. Gmail and Outlook will still deliver the message in many cases, but they flag it with a warning. More critically, if you also have a strict DMARC policy, a failed SPF check can cause the email to be rejected entirely.
For signature tracking, the problem is subtle. Even if the email lands in the inbox, a soft SPF fail can cause the receiving server to defer loading external images. The pixel may load inconsistently, inflating your open rate variance.
How to set it up
- Determine the IP ranges or hostnames your sending service uses. Most ESPs publish this in their documentation.
- Add a TXT record to your DNS like:
v=spf1 include:_spf.your-esp.com ~all - Use
~all(softfail) during testing, then switch to-all(hardfail) once confirmed.
Do not use +all. That allows any server to send as your domain.
DKIM: the cryptographic signature that proves integrity
DomainKeys Identified Mail (DKIM) adds a digital signature to the headers of your email. The signature is generated using a private key held by your sending infrastructure, and verified by the receiving server using a public key published in your DNS.
DKIM is more resilient than SPF because it survives email forwarding. If your email is forwarded from a Gmail alias to an Outlook inbox, the SPF check may fail (the forwarder's IP is not in your SPF record), but the DKIM signature remains intact. This makes DKIM essential for any email that might be forwarded — and signature-tracked emails are often forwarded.
Why DKIM matters for your tracking pixel
When DKIM passes, the receiving server trusts that the email has not been tampered with in transit. This trust extends to external content like tracking pixels. Servers that strip external images for unauthenticated email often load them when DKIM passes.
Most signature trackers embed the pixel in the HTML signature using an absolute URL. If DKIM fails, the email may still be delivered, but the pixel URL may be rewritten or blocked by content security policies. DKIM validation gives you the best chance of that pixel loading as intended.
How to set it up
Your ESP or email platform will generate a DKIM key pair. You publish the public key as a TXT record under a subdomain like google._domainkey.yourdomain.com. The selector (the part before _domainkey) varies by provider.
Common defaults:
- Gmail/Google Workspace: selector
google - Microsoft 365: selector
selector1orselector2 - Amazon SES: selector generated per region
After publishing, wait for DNS propagation and verify with a tool like dig or an online DKIM checker.
DMARC: the policy that ties it all together
DMARC (Domain-based Message Authentication, Reporting & Conformance) tells receiving servers what to do when SPF and DKIM checks fail. It also provides reporting so you can see who is sending email using your domain.
Without a DMARC policy, receiving servers apply their own default behaviour. Some deliver the email anyway; others quarantine it. This inconsistency is deadly for signature tracking because you cannot predict whether your pixel will load.
The three policy levels
p=none— Monitor only. No action taken. Use this to collect data without affecting delivery.p=quarantine— Mark failing email as spam. Gmail and Outlook will typically move it to the spam folder.p=reject— Reject failing email outright. The receiving server will not deliver it at all.
For signature tracking, you want p=quarantine or p=reject only after you are confident SPF and DKIM are correctly configured. A p=reject policy with broken SPF or DKIM will silently kill your open rates.
Alignment and the tracking pixel domain
DMARC also checks "alignment" — whether the domain in the From header matches the domain used in SPF or DKIM. If you send from [email protected] but your tracking pixel is served from tracker.thirdparty.com, DMARC alignment is unaffected because the pixel is an external resource, not a header domain.
However, some aggressive content security policies (CSP) on the receiving side may block images from unknown domains. This is not a DMARC issue, but it is worth noting: if your tracker uses a custom tracking domain that matches your sending domain, you eliminate that extra risk.
Common misconfigurations that break signature tracking
Even with all three protocols in place, small mistakes can cause failures. Here are the most common ones you will encounter:
- Missing DKIM selector for forwarded email. If you use a subdomain like
mail.yourdomain.comfor sending, the DKIM record must be on that subdomain, not the root domain. Forwarding services often check the subdomain's DNS. - SPF record too long. DNS has a 255-character limit per string. If your SPF record includes too many
include:statements, it may be truncated. Use a singleinclude:for your ESP and avoid stacking multiple providers. - DMARC policy set to
p=rejectbefore SPF and DKIM are fully deployed. This is the most common cause of "my emails stopped arriving" complaints. Always start withp=none, review reports for a week, then tighten.
How newmail.click handles this
newmail.click is a free email signature builder with optional Pro-tier click and open tracking. When you use our Pro tracking, the pixel and link redirects are served from our infrastructure. We do not touch your DNS — you must configure SPF, DKIM, and DMARC on your own sending domain. Our role is to ensure the tracking endpoints are reliable and that our redirects do not interfere with your authentication. We also provide default UTM parameters for tracked links and can send Slack or email alerts when opens or clicks occur. If your email fails authentication, our alerts will still fire for any events that do register, but the open rate will be underreported. The fix is always on your DNS side, not ours.
The one thing you must verify before relying on open tracking
Run a test. Send an email with your signature tracker to a Gmail address, then view the raw headers. Look for Authentication-Results. You should see spf=pass, dkim=pass, and dmarc=pass. If any of these say fail or neutral, your tracking pixel is at risk.
After you confirm authentication passes, send a second test to a tool like Mail-Tester.com or GlockApps. These will show you whether external images are being blocked. If images load, your signature tracker will work consistently.
Do not assume that because your email arrives, the pixel loads. Many servers deliver email but strip external content until the user clicks "show images". Proper authentication reduces that friction.