To authorize third-party senders under DMARC: 1) Discover all services sending as your domain using DMARC aggregate reports, 2) For each legitimate service: add their SPF include to your record AND configure custom DKIM signing if the service supports it, 3) Services that can't be authenticated: change their From: address to use the service's own domain instead of yours. Common third-party senders people forget: helpdesks (Zendesk), billing (Stripe/QuickBooks), booking tools (Calendly), form processors (Typeform), and project management tools.
DMARC and Third-Party Senders: How to Authorize Safely
The Discovery Process
Step 1: Collect DMARC Reports
v=DMARC1; p=none; rua=mailto:[email protected]
Wait 2-4 weeks. Every server that processes your email sends daily reports.
Step 2: Parse Reports
Use dmarcian (free tier) or Postmark DMARC (free digest). Reports show:
| Source IP | Service | Volume | SPF | DKIM | DMARC |
|---|---|---|---|---|---|
| 209.85.x.x | Google Workspace | 500/day | Pass | Pass | Pass ✓ |
| 167.89.x.x | SendGrid | 200/day | Pass | Pass | Pass ✓ |
| 198.2.x.x | Mailgun | 50/day | Pass | Fail | Fail ✗ |
| 3.x.x.x | Calendly | 5/day | Fail | None | Fail ✗ |
| 52.x.x.x | Unknown | 2/day | Fail | Fail | Fail ✗ |
Step 3: Categorize Each Sender
Authorized + Passing: Google Workspace, SendGrid — properly configured. ✓
Authorized + Failing: Mailgun (DKIM not configured), Calendly (not in SPF, no DKIM). Fix these.
Unknown + Failing: Could be spoofing (block it) or a forgotten service (investigate).
Step 4: Authorize Legitimate Services
For each legitimate service that's failing:
Option A: SPF + DKIM (best)
- Add service's SPF include to your record
- Configure custom DKIM in the service's settings
- Verify both pass
Option B: SPF only (if no DKIM support)
- Add service's SPF include to your record
- Ensure SPF alignment (Return-Path domain matches From:)
- May work for DMARC if alignment is correct
Option C: Subdomain (if SPF/DKIM not feasible)
- Route through a subdomain: support.yourdomain.com
- Configure SPF and DKIM on the subdomain
- Service sends from [email protected]
Option D: Change From: address (last resort)
- Configure the service to send from its own domain
- "via zendesk.com" or "[email protected]"
- No authentication impact on your domain
Common Third-Party Services
| Service | SPF Include | Custom DKIM? | Notes |
|---|---|---|---|
| Zendesk | include:mail.zendesk.com | Yes | Support replies as your domain |
| Freshdesk | include:email.freshdesk.com | Yes | Support replies |
| HubSpot | include:spf.hubspot.com | Yes | Sales and marketing email |
| Salesforce | Multiple | Yes | CRM email |
| Calendly | Varies | Limited | Booking confirmations |
| Stripe | N/A | No | Receipts — usually sends from Stripe's domain |
| QuickBooks | Varies | Limited | Invoices |
| Typeform | N/A | No | Form confirmations — send from their domain |
| Slack | N/A | No | Notification emails from Slack's domain |
Key insight: Not every service needs to send from YOUR domain. Stripe receipts from stripe.com are fine. Calendly confirmations from calendly.com are fine. Only authorize services that MUST send as your domain.
The Authorization Decision Tree
Is this service sending as my domain?
├── YES — Is it legitimate?
│ ├── YES — Does it support custom DKIM?
│ │ ├── YES → Add SPF include + configure DKIM ✓
│ │ └── NO → Can it send from a subdomain?
│ │ ├── YES → Route through subdomain ✓
│ │ └── NO → Change to send from service's own domain ✓
│ └── NO (spoofing) → DMARC at p=reject will block it ✓
└── NO → No action needed
Practitioner note: The most common surprise in DMARC reports: a booking tool (Calendly, Acuity) sending confirmation emails as your domain. Someone on the team connected it months ago and nobody updated SPF. At p=none: works fine. At p=quarantine: booking confirmations go to spam. At p=reject: customers never receive booking confirmations. Discover these before advancing DMARC.
Practitioner note: My rule for third-party authorization: if the service supports custom DKIM, configure it. If it doesn't, ask "does this really need to send from my domain?" Most services work fine sending from their own domain. Only CRM and helpdesk typically need to send as your domain for reply-handling purposes.
For the complete DMARC setup process, see the DMARC setup guide. For understanding the reports that reveal third-party senders, see DMARC report interpretation. For managing SPF across multiple senders without hitting limits, see SPF, DKIM, DMARC for multiple senders. If you need third-party senders identified and authorized for DMARC advancement, schedule a consultation.
Sources
- RFC 7489: DMARC
- dmarcian: Third-Party Senders
v1.0 · March 2026
Frequently Asked Questions
How do I find all third-party services sending as my domain?
DMARC aggregate reports. Set up DMARC at p=none with rua= to receive reports. After 2-4 weeks, your reports show every IP that sent email claiming to be from your domain. Use dmarcian or Postmark DMARC to parse the reports and identify each sender.
What if a third-party service doesn't support custom DKIM?
If the service can't sign with your domain's DKIM: 1) Add their SPF to your record (SPF alignment may work), 2) If SPF alignment also fails: change the service to send from its own domain (e.g., 'via zendesk.com' instead of 'from yourdomain.com'), 3) Or use a subdomain: support.yourdomain.com with the service's authentication.
Which third-party services commonly break DMARC?
Helpdesks (Zendesk, Freshdesk) — send support replies as your domain. Billing (Stripe, QuickBooks) — send invoices/receipts. Booking (Calendly, Acuity) — send confirmations. Forms (Typeform, Jotform) — send form response emails. CRM (HubSpot, Salesforce) — send sales email. Project tools (Monday, Asana) — send notification emails.
Can I authorize third-party senders without adding them to SPF?
Yes, if they support custom DKIM signing with your domain. DMARC passes when EITHER SPF or DKIM aligns. DKIM-only authorization keeps your SPF record cleaner (important for the 10-lookup limit). Check if the service supports custom DKIM before adding to SPF.
What happens to unauthorized third-party senders at p=reject?
Their email is rejected entirely — it never arrives. This is why DMARC advancement requires discovering and authorizing ALL legitimate senders first. At p=none: the email delivers (reported but not blocked). At p=reject: the email is blocked.
Want this handled for you?
Free 30-minute strategy call. Walk away with a plan either way.