Cold Emailing
CEO and co-founder
Email Authentication for Cold Email at Agency Scale: SPF, DKIM, and DMARC Explained
TL;DR: SPF, DKIM, and DMARC are mandatory for inbox placement: Google and Yahoo enforce them for bulk senders, and Microsoft applies stricter enforcement for authentication failures, with unauthenticated messages facing a higher likelihood of quarantine or rejection. At agency scale, configuring these records manually across 50-200 domains takes 12 or more hours initially and introduces the kind of typo-driven failures that kill campaigns silently. Inframail automates all three records on domain setup, with customers reporting 10 inboxes provisioned in under two minutes.
If you manage 50 or more cold email domains and still copy-paste SPF records into Cloudflare by hand, one typo can send that domain's entire sending volume to the spam folder. That is not hypothetical. It is what happens when DNS configuration at scale meets human error, repeated across dozens of domains every month.
Email authentication is the technical foundation that receiving servers use to verify your identity before accepting your messages. Google and Yahoo require bulk senders (those sending 5,000 or more emails per day) to implement SPF, DKIM, and DMARC together, with enforcement action taken against non-compliant senders. Getting these records right is the cost of admission to the inbox. Getting them right across 50-200 domains manually is an operational margin-killer that agencies can automate using flat-rate infrastructure.
How Misconfigured Records Trigger Spam Filters
When your email arrives at Gmail or Outlook, the receiving server runs DNS lookups in milliseconds to answer one question: is this sender who they claim to be? If your SPF, DKIM, or DMARC records are missing, broken, or misaligned, the answer is "no" and your email either lands in spam or bounces with a hard rejection error.
The most common hard rejection you will see is a 554 5.7.5 permanent error evaluating DMARC policy, which means the receiving server rejected your message because it failed authentication checks. The 550 5.7.1 variant indicates the message was rejected by the recipient server's policy, which can signal an authentication failure, blacklisting, or content rejection. The specific wording varies by server, though some display "Unauthenticated mail is prohibited." Both errors look like deliverability problems to the client, but the root cause is often a DNS record, not your copy or targeting.
Separating auth from inbox success
Authentication is a prerequisite for deliverability, not a guarantee of it. Passing authentication checks proves your identity to the receiving server, but it does not earn inbox placement on its own. Sender reputation, domain age, sending volume, and message content all determine whether your email ends up in the primary tab, promotions, or spam. Think of authentication as a mandatory entry requirement: you cannot get through the door without it, but getting through the door does not guarantee you will stay.
Tracking DMARC errors in cold email
DMARC failures in cold email campaigns do not always surface as obvious bounce codes and can instead appear as unusually low open rates or a generic deliverability drop that everyone blames on the copy. When a domain fails DMARC, the Authentication-Results header shows dmarc=fail, but most campaign managers never read raw headers. The first sign of a DMARC failure is usually a campaign that stops producing replies, which gets misattributed to targeting while the actual DNS problem can go unfixed for days or weeks. Our infrastructure monitoring guide covers how to set up alerts that catch these failures before they kill a campaign.
Microsoft vs. Google authentication differences
Google typically sends unauthenticated emails to spam. Microsoft applies stricter enforcement for authentication failures than Gmail. According to Microsoft's own documentation, unauthenticated or misaligned messages face a higher likelihood of being quarantined or rejected, as the system weighs authentication results alongside the overall suspicious nature of a message. Configuration errors such as exceeding the SPF 10-lookup limit can trigger significant filtering even when your content is clean.
SPF records for cold email sending domains
This section covers how SPF records work at a technical level, the most common setup errors that break authentication, and how to validate your records before launching campaigns.
Sender Policy Framework, defined in RFC 7208, is a DNS text record that lists every IP address and mail server authorized to send email on behalf of your domain. When a receiving server processes your message, it looks up the SPF record of the Return-Path domain (the envelope-from address, not the visible From header) and checks whether the sending IP appears on that list.
How SPF ensures inbox placement
If the sending IP matches the SPF record, the check returns pass. If it does not match, the check returns fail, softfail, or neutral depending on your policy. A PermError occurs when the SPF record has a configuration problem, most commonly exceeding the 10-lookup limit. The SPF specification in RFC 7208 enforces a hard ceiling of 10 DNS lookups per evaluation; exceeding it typically causes authentication to fail, and most mail servers will filter or reject the message.
Anatomy of a valid SPF record
A standard SPF record for a cold email sending domain looks like this:
v=spf1 include:spf.inframail.io ~all
Component | Meaning |
|---|---|
| Version identifier, required at the start of every SPF record |
| Authorizes IPs listed in Inframail's SPF record |
| Soft fail: typically flags but does not reject unlisted senders |
| Hard fail: typically rejects senders not explicitly listed |
For cold email domains, ~all (soft fail) is widely recommended when DMARC is properly configured. As Red Sift's SPF guidance explains, when paired with DMARC and DKIM, soft fail typically provides equal protection against spoofing without risking lost messages or deliverability problems from minor alignment edge cases.
SPF setup for cold email domains
Manual SPF setup in Namecheap follows this sequence for each domain:
Log in to your DNS panel and navigate to Advanced DNS.
Create a new TXT record with host set to
@.Enter the full SPF string (e.g.,
v=spf1 include:spf.inframail.io ~all) in the value field.Set TTL to automatic and save the record.
Repeat for each domain in your portfolio.
For a large domain portfolio, that process runs for separate login sessions and multiple copy-paste operations per domain. We eliminate this entirely. Our automated setup provisions SPF, DKIM, and DMARC records when you purchase or migrate a domain, no DNS panel access required.
Top 5 SPF setup errors to avoid
Multiple SPF records on one domain: Having more than one TXT record starting with
v=spf1invalidates both records immediately. Combine all authorized senders into a single record.Exceeding the 10-lookup limit: Every
include:statement counts as a lookup. Chain too many and SPF returnsPermError, which causes authentication to fail hard.Typos in the include statement: A single misspelled character produces a lookup failure. Validate every record after setup using MXToolbox's SPF lookup tool.
Using the wrong qualifier without DMARC context: If you use
allwithout a DMARC record in place, minor misalignments that would otherwise be recoverable become hard rejections.Forgetting to update records after changing providers: If you switch sending infrastructure and leave old include statements in the record, you accumulate unnecessary lookups and risk hitting the 10-lookup ceiling.
Validating your SPF record setup
Run these two tests before launching campaigns:
Mail-Tester: Send a test email to your unique Mail-Tester address and confirm SPF shows as
passwith a score of 9/10 or higher.MXToolbox SPF lookup: Use MXToolbox's SPF tool to check record syntax and count DNS lookups (must stay under 10 to avoid
PermError).
Technical steps for DKIM signature setup
This section covers how DKIM signing works, the DNS requirements for publishing your public key, and how to identify the causes of signature failures.
DomainKeys Identified Mail, defined in RFC 6376, uses cryptographic signatures to prove that your email content was not altered between the sending server and the receiving server.
The mechanics of DKIM signature verification
When your sending server dispatches an email, it signs specific parts of the message header and body using a private key. The corresponding public key lives in your domain's DNS as a TXT record. When the receiving server processes the message, it retrieves that public key from DNS and uses it to decrypt the signature in the DKIM-Signature header. If the decrypted hash matches the actual message content, DKIM passes.
DNS requirements for DKIM keys
A DKIM TXT record sits at a specific subdomain following this format:
selector._domainkey.yourdomain.com
The record value contains the public key string starting with v=DKIM1;k=rsa;p= followed by the Base64-encoded public key. In Namecheap, enter this as a TXT record where the host field is selector._domainkey and the value is the full key string without brackets or quotes.
DKIM selector strategy for multiple domains
A selector is the label that identifies which DKIM key pair to use when a domain has multiple sending services. For agencies managing many domains, a consistent naming convention for selectors can simplify bulk management: you know the exact subdomain format for every domain in your portfolio without checking each one individually. Pick one selector name and apply it to every domain you provision.
DKIM alignment and signature validation
DKIM alignment requires that the domain in the d= field of the DKIM-Signature header matches the domain in the visible From header. For cold email, this means your sending domain and your From address domain must match exactly, or share the same parent domain under relaxed alignment. A DKIM record can be technically valid yet still fail DMARC if this alignment check does not pass, which is a common configuration mistake at agency scale.
How to debug failed DKIM signatures
When DKIM fails, check these causes in order:
Key truncation in the DNS panel: Many DNS panels have character limits on TXT record values. If the public key string was cut off during entry, DKIM will fail every verification.
Copy-paste errors: A single extra space or missing character in the key string breaks the cryptographic check.
Wrong selector format: The hostname
selector._domainkeymust include._domainkeyas a suffix, not just the selector name alone.
Our DKIM and SPF setup walkthrough shows the exact process for configuring records for 10 or more inboxes in under ten minutes using automated provisioning.
DMARC policies for 50-200 sending domains
This section covers how DMARC ties SPF and DKIM together, which policy settings apply to cold email domains, and how to read the aggregate reports DMARC generates.
Domain-based Message Authentication, Reporting, and Conformance, defined in RFC 7489, ties SPF and DKIM together and tells receiving servers what to do when either check fails. For DMARC to pass, typically either SPF or DKIM must pass, and the passing check must align with the domain in the From header. Both do not need to pass simultaneously, as Valimail's DMARC explainer confirms.
DMARC benefits for 50+ inboxes
At agency scale, DMARC serves two functions. First, it prevents domain spoofing by telling receivers to quarantine or reject emails that do not pass authentication checks. Second, it generates aggregate XML reports (sent to the rua address in your record) showing every IP address that attempted to send from your domain, along with SPF and DKIM pass or fail counts. This is critical for catching unauthorized sending, identifying misconfigured systems, or spotting compromised accounts across a large domain portfolio.
Google and Yahoo's bulk sender requirements mandate a DMARC policy for senders exceeding 5,000 emails per day, with spam complaint rates required to stay below 0.3%. Cold email agencies sending at scale across multiple client accounts will exceed this threshold across their collective sending volume.
Correct DMARC setup for cold email
A standard cold email DMARC record looks like this:
v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com
Add this as a TXT record in DNS with the host set to _dmarc and the value containing the full string above. Use a mailbox you actively monitor for the rua tag, since these reports identify authentication failures and unauthorized sending sources.
Policy settings for cold email (p=none vs. p=quarantine)
Policy | Effect | When to use |
|---|---|---|
| Monitor only, typically no enforcement | Cold email domains, new setups, testing |
| Failed emails typically go to spam folder | Established domains with clean history |
| Failed emails are typically blocked entirely | Mature domains with perfect, stable alignment |
Start with p=none for all cold email domains. This lets you receive DMARC reports without risking delivery blocks from any alignment edge case. After reviewing reports and confirming clean authentication across your sending patterns, you can move to p=quarantine. Avoid using p=reject on active cold email domains: any minor alignment issue can cause immediate email deletion with no recovery.
DMARC alignment modes (relaxed vs. strict)
DMARC alignment comes in two modes defined in RFC 7489 Section 3.1.2. Relaxed alignment typically allows subdomains to match the parent domain, so mail.yourdomain.com passes alignment for yourdomain.com. Strict alignment requires an exact match between the From header domain and the SPF or DKIM domain. For cold email, relaxed alignment is generally preferable. Strict alignment can fail when sending platforms use subdomains as the Return-Path, which is standard behavior for most cold email tools.
How to analyze DMARC forensic data
DMARC aggregate reports arrive as XML files that are not human-readable without a parser. GlockApps and dmarcian both convert these reports into readable dashboards showing authentication pass and fail rates by source IP, letting you identify misconfigured domains or unauthorized senders within your portfolio.
Optimizing authentication for Gmail and Outlook
The two primary inbox providers that cold email agencies send to handle authentication differently and require different tactical approaches to achieve consistent inbox placement.
Why Microsoft blocks cold email domains
Microsoft's filtering algorithms apply aggressive enforcement, particularly for domains on shared IP pools. When one sender on a shared IP pool gets flagged for spam behavior, the entire IP range can be temporarily blocked, and every other sender using that pool gets caught in the same block. Shared IP infrastructure typically operates this way: your sending reputation can be affected by the behavior of other senders on the pool. Our Maildoso deliverability review covers how shared IP contamination creates unpredictable inbox rates in practice.
Dedicated IPs solve this problem directly. Our Unlimited Plan includes one dedicated US-based IP. Our Agency Pack includes three. This means your sending reputation is determined exclusively by your own sending behavior. Our guide to getting off the Microsoft blacklist covers the delisting process for Microsoft-blocked domains.
Outlook specific SPF DKIM DMARC rules
Microsoft's Exchange Online Protection evaluates SPF, DKIM, and DMARC together before applying spam scoring. Configuration errors that cause your SPF record to exceed the 10-lookup limit can trigger significant filtering for Outlook recipients even when your content is clean.
Microsoft's documentation confirms that if SPF, DKIM, or DMARC are missing or misconfigured, legitimate messages may be delivered to the Junk Email folder or quarantine. Having DKIM present and passing typically improves spam score outcomes across Microsoft's filtering layers.
Gmail's SPF and DKIM thresholds
Google reportedly requires all senders to have SPF or DKIM configured, and bulk senders above 5,000 daily emails must have both SPF and DKIM plus a DMARC policy. Spam complaint rates above 0.3% reportedly trigger filtering and eventual sending restrictions. For cold email agencies, monitoring complaint rates using Google Postmaster Tools across all client domains provides early warning before campaign performance degrades. Our video on increasing cold email deliverability covers how to keep complaint rates below threshold at scale.
Managing authentication at agency scale
Keeping 150 domains simultaneously compliant with both Google and Microsoft standards requires a systematic approach. Every new client domain needs SPF, DKIM, and DMARC records configured before any warmup or sending begins. Any change to your sending infrastructure, such as switching platforms or adding a new sending tool, requires updating SPF records across all domains. Manual management of this at scale is operationally risky because a single missed update breaks authentication for every domain that relies on that include statement.
How to configure bulk authentication for agencies
The following DNS configuration table gives you a quick-reference guide for manual setup across all three protocols.
Table 1: DNS record configuration guide
Record type | Host / Name | Value / Target | Purpose |
|---|---|---|---|
TXT (SPF) |
|
| Authorize sending IPs for your domain |
TXT (DKIM) |
|
| Publish your DKIM public key |
TXT (DMARC) |
|
| Set enforcement policy and enable reporting |
Configuring SPF, DKIM, and DMARC
Manual configuration for 50 domains follows this sequence for each domain:
Log in to DNS panel (Namecheap, Cloudflare, etc.)
Create SPF TXT record at
@Create DKIM TXT record at the selector subdomain
Create DMARC TXT record at
_dmarcVerify propagation (24-48 hours)
Test using Mail-Tester or MXToolbox
Manual configuration for multiple domains can be time-consuming, with each domain requiring login, record creation, verification, and testing. For agencies with regular client onboarding, this is a recurring operational cost that compounds as domain volume grows.
Automate DNS and SPF for cold email
We provision SPF, DKIM, and DMARC records automatically when you purchase or migrate a domain to Inframail. You do not access a DNS panel, copy key strings, or check propagation manually. The platform configures all three records in seconds and generates credentials for each inbox, which you can export and import directly to Instantly.ai or Smartlead.
Our SPF, DKIM, and DMARC setup walkthrough shows the complete process from domain purchase through DNS auto-configuration to CSV export, with timestamps visible throughout.
How long until domains are ready
DNS propagation typically completes within 24-48 hours globally, though records often appear on major mail servers in less time depending on TTL settings and registrar configuration. Our Inframail help center recommends beginning inbox warmup immediately after domain setup using external warmup tools like Warmbox or Lemwarm.
Validating SPF, DKIM, and DMARC settings
See Table 2 at the end of this article for a full cost breakdown across 50, 100, and 200 inboxes. Run this validation checklist on every new domain batch before launching campaigns:
Send a test email to your Mail-Tester unique address and confirm SPF, DKIM, and DMARC all show as
passwith a score of 9/10 or higherUse MXToolbox's SPF lookup to count DNS lookups and confirm you are below the 10-lookup limit
Check the
Authentication-Resultsheader in Gmail by opening your test email, clicking the three-dot menu, selecting "Show original," and confirming all three checks showpassConfirm the DMARC
ruaemail address is receiving aggregate reports within 24 hours of sending
Our infrastructure consistently scores 9.5 out of 10 on Mail-Tester across tested domains. Our campaign spam metrics guide covers how to read open rates, bounce rates, and spam metrics from your sending platform to identify when delivery problems are developing.
Audit your setup to stop email bounce issues
When campaigns produce hard bounces or unusual drops in open rates, the first place to look is the authentication header, not the copy.
Recognizing SPF DKIM DMARC errors
The most common bounce codes for authentication failures are:
554 5.7.5- Permanent error evaluating DMARC policy. Check SPF and DKIM pass status and domain alignment.550 5.7.1- Rejected by DMARC policy. Authentication failure at the MTA level.550 5.7.26- Unauthenticated mail is prohibited. Google's enforcement code for missing or failed authentication on bulk-sender domains. Confirm SPF and DKIM are both present and passing, and that your DMARC policy is in place.
Any of these bounce codes appearing in your campaign logs means the problem is in your DNS records, not your sending behavior.
Using Mail-Tester and GlockApps for diagnosis
Mail-Tester provides a per-domain score with line-item breakdowns showing exactly which record failed, whether the DKIM public key was found, whether the SPF record resolved correctly, and whether the DMARC policy is in place. GlockApps goes further by testing inbox placement across Gmail, Outlook, Yahoo, and other major providers simultaneously, giving you a platform-by-platform breakdown of where emails land. In our own GMass testing, we recorded an 88% inbox placement rate, and GlockApps reports provide the granular breakdown that shows whether that rate holds across both Gmail and Outlook.
Validate SPF DKIM and DMARC headers
Open any sent email in Gmail and select "Show original" from the three-dot menu. Look for the Authentication-Results section near the top of the raw headers:
Any check showing fail or softfail identifies exactly which record needs fixing. In Outlook, select "View" then "View Message Source" to access the same header information.
When sender reputation is the culprit
If all authentication checks pass but delivery rates are still low, the problem is not authentication, it is sender or IP reputation. A domain that passed authentication but sent high volumes of un-warmed emails, experienced elevated spam complaints, or sat on a blacklisted IP may still fail inbox placement even with perfect DNS records. Our infrastructure monitoring guide covers how to distinguish authentication failures from reputation failures using blacklist monitoring and GlockApps reputation scores.
Troubleshooting your SPF, DKIM, and DMARC setup
The questions below address the most common configuration decisions and failure points across SPF, DKIM, and DMARC for agencies sending at scale.
Do I need all three protocols (SPF, DKIM, DMARC)?
If you are a bulk sender (5,000 or more emails per day), yes. Google and Yahoo reportedly require SPF, DKIM, and DMARC together for bulk senders, and Microsoft applies stricter authentication enforcement than Gmail, with unauthenticated messages more likely to be quarantined or rejected. For lower-volume senders, Google requires at minimum SPF or DKIM, but running all three dramatically improves deliverability and protects your domain from spoofing.
Timeline for SPF and DKIM activation
DNS propagation typically completes in 24-48 hours globally, though records can appear on individual mail servers faster depending on TTL settings. Consider waiting at least 24 hours before launching active campaigns on newly configured domains to avoid delivery failures during propagation.
Do SPF and DKIM prevent domain bans?
No. Authentication verifies your identity, but does not protect your reputation. Sending to low-quality lists, triggering spam complaints above Google's 0.3% threshold, or sending from un-warmed inboxes can result in domain bans and blacklisting regardless of authentication status. Warm every inbox using an external warmup tool before sending campaigns.
Alignment vs. validation in authentication
A DNS record can be technically valid and still fail DMARC. Validation checks whether the record exists and is correctly formatted. Alignment checks whether the domain in your From header matches the domains validated by SPF and DKIM. Both must be correct for DMARC to succeed. An SPF record that correctly lists your sending IP but points to a different domain than your From header will fail DMARC alignment even though SPF itself passes.
Should I use p=reject for cold email domains?
No. Use p=none for all active cold email domains. If any minor alignment issue occurs, p=reject can cause immediate email deletion with no bounce code and no recovery. Agencies running 50-200 domains will encounter alignment edge cases, and p=reject can turn those edge cases into complete campaign failures with no diagnostic data.
Proper authentication at scale is an infrastructure problem, not a DNS knowledge problem. Campaign managers who spend 12-plus hours monthly copying records into Cloudflare and Namecheap are treating a systems problem as a manual task. The Inframail to Smartlead integration guide and the Maildoso migration guide both show how automated infrastructure handles the DNS layer so operators focus on campaign performance instead.
Table 2: Total cost of ownership - 50, 100, and 200 inboxes
The following table shows total monthly and annual savings when switching from Google Workspace to Inframail across three common agency scales:
Inbox count | Google Workspace cost | Inframail cost (platform + domains) | Monthly savings | Annual savings |
|---|---|---|---|---|
50 inboxes | $350-420/month | $129 + ~$34 domains = $163/month | $187-257/month | $2,244-3,084 |
100 inboxes | Approximately $700-840/month | Approximately $171-262/month | Approximately $438-678/month | Approximately $5,256-8,136 |
200 inboxes | Approximately $1,400-1,680/month | Approximately $212-396/month | Approximately $1,004-1,468/month | Approximately $12,048-17,616 |
Google Workspace Business Starter at $7-8.40 per user per month. Inframail domains at $5-16 per year amortized. Inframail Unlimited Plan at $129/month for unlimited inboxes.
External warmup tools (e.g., Warmbox or Lemwarm) add approximately $15-50/month and are required regardless of infrastructure provider. This cost applies equally to Google Workspace and Inframail setups and does not affect the net savings figures above.
100 and 200 inbox cost figures are estimates calculated from the stated domain price range ($5-16/year per domain, amortized monthly) and the $129/month Unlimited Plan flat rate. No verified company profile figure exists for these tiers. Actual costs will vary based on registrar pricing and domain count.
At 200 inboxes, Google Workspace infrastructure costs approximately $1,400-1,680 per month. Our estimated infrastructure costs approximately $212-396 per month. That difference, approximately $1,004-1,468 monthly, is the margin that determines whether an agency growing from 50 to 200 inboxes stays profitable or starts cutting client services to cover infrastructure bills.
"InfraMail makes it remarkably easy to purchase domains, configure them correctly, and create inboxes. The level of automation is exceptional and clearly designed for serious operators; it removes friction and allows you to focus on execution rather than setup." - Verified user review of Inframail
If you are managing 50 or more cold email domains and still configuring SPF, DKIM, and DMARC by hand, sign up to Inframail and get started today. Inframail automates all three DNS records on domain setup, provisions unlimited inboxes at a flat rate of $129/month, and includes dedicated IP infrastructure so your sending reputation stays isolated from other senders.
FAQs
How long does it take for SPF and DKIM records to propagate?
DNS propagation typically completes in 24 to 48 hours globally, though individual mail servers may reflect new records sooner depending on TTL settings. Consider waiting at least 24 hours before launching active campaigns on newly configured domains.
Do SPF and DKIM records prevent my domains from getting blacklisted?
No, authentication only verifies your identity to email service providers. If you send high volumes of un-warmed emails or use spammy copy, your domains can still get blacklisted regardless of perfect authentication records.
Can I use multiple SPF records on a single cold email domain?
No. Having more than one SPF record on a domain invalidates both records and causes immediate authentication failure. You must combine all authorized senders into a single SPF record.
What is the SPF 10-lookup limit and why does it matter for cold email?
The SPF specification in RFC 7208 allows a maximum of 10 DNS lookups per evaluation. Exceeding this limit returns a PermError, which causes severe filtering or rejection at most major mail servers.
What DMARC policy should a cold email agency use?
Start with p=none across all active sending domains. This enables aggregate reporting without risking delivery failures from alignment edge cases, and move to p=quarantine only after reviewing DMARC reports and confirming clean authentication.
How does DMARC alignment differ from DMARC validation?
Validation checks whether your SPF and DKIM records are correctly formatted and exist in DNS. Alignment checks whether the domain in those records matches your visible From header domain, and a record can pass validation but still fail DMARC if the domains do not align.
Key terms glossary
SPF (Sender Policy Framework): A DNS text record that lists all authorized IP addresses allowed to send emails on behalf of your domain, as defined in RFC 7208.
DKIM (DomainKeys Identified Mail): A cryptographic authentication method that adds a digital signature to your email headers to prove the message was not altered in transit, as defined in RFC 6376.
DMARC (Domain-based Message Authentication, Reporting, and Conformance): An email authentication protocol that uses SPF and DKIM to determine the authenticity of an email message and specifies how receivers should handle failures, as defined in RFC 7489.
Domain alignment: A security check requiring the domain in your visible "From" header to match the domains validated by SPF and DKIM for DMARC to pass.
Dedicated IP: An IP address used exclusively by a single sender, ensuring your email deliverability is not affected by the sending behavior of other users on a shared pool.
DNS propagation: The time it takes for a newly created or updated DNS record to appear on all DNS servers globally, typically 24-48 hours. During propagation, some mail servers may see your new records while others still see old records.
SPF PermError: An error returned when an SPF evaluation fails due to a configuration problem, most commonly exceeding the 10-lookup limit, which causes authentication to fail and emails to be filtered or rejected.
DMARC aggregate report: An XML report sent to the address specified in the rua tag of your DMARC record, showing all sources that attempted to send from your domain and their authentication pass or fail status.
