CustomerGauge works hard to ensure that its own email sending domain has a high reputation, as this is important in ensuring that survey invitations arrive in the inbox of intended B2B recipients.


Equally, CustomerGauge will assist our clients who want to send from their own (sub)domain and, of course, still obtain a good inbox placement.


Specifically, CustomerGauge will:

  • Advise the client's IT department on how to set up the appropriate DNS records (SPF, DKIM, DMARC).
  • Provide a high-reputation, fixed sending IP.

But note that when using a 'Custom Sending Domain' the client themselves are responsible for the reputation of their own subdomain.


However, even with correct DNS declarations and good (sub)domain and IP reputations, inbox placement is not guaranteed as every receiving organization has its own tooling and policies designed to protect employees from unwanted emails. Spam filters are often configured aggressively and may block unexpected correspondence, regardless of the positive reputation of the sending domain.


If you hear that your intended survey recipients are not receiving email invites, the first step is to ask the receiving organization to add your sending domain to their whitelist. This is typically handled by their IT department via the corporate anti-spam filter. If that’s not an option, encourage individual recipients to check their spam folders and mark your survey invitations as 'Safe' or 'Not Spam'. When multiple recipients do this, many spam filtering systems will learn that your emails are trusted and adjust their filtering behavior accordingly.


If the problem persists, it may be necessary to review the survey invitation content itself, as spam filters often weigh content as heavily as technical settings. 


Best practices for avoiding content-related spam triggers include:

  • Avoiding "spammy" phrases like “Act Now”, “Free!!!”, “Click Here”, or excessive use of all caps and exclamation marks.
  • Keeping formatting simple and professional, avoiding large red fonts, garish colors, or overly promotional language.
  • Using a balanced text-to-image ratio: too many images or image-only emails are often flagged as suspicious.
  • Making unsubscribe links visible and not hidden or obscured — this builds trust and is often required for compliance.
  • Ensuring all embedded links use reputable domains and are relevant — avoid URL shorteners or domains with low trust scores.
  • Crafting a clear subject line with no misleading content or clickbait phrasing.
  • Personalizing the email where possible, using recipient names or account-specific context, as generic messaging is more likely to be filtered.
  • Testing your email using spam-check tools (such as Mail-Tester or GlockApps) before sending large campaigns, to catch potential triggers.


By combining good technical setup, careful monitoring of bounce/spam metrics, and thoughtful content creation, you significantly increase the likelihood of successful inbox placement.




Understanding the importance of authorized (sub-)domains

While not strictly mandatory, DKIM, SPF, and DMARC play an important role in email authentication. Setting up DKIM, SPF, and DMARC significantly enhances email deliverability for the domain in question. Note: Setting these up does not guarantee 100% email deliverability. 



Important Email Sending Requirements and Throttling Considerations

Inbox service providers favor DKIM-authenticated emails, as those without DKIM authentication are more prone to bouncing, quarantine, or being labeled as spam. Although quarantined emails may register as delivered in CustomerGauge, they won't be visible to most recipients. So setting up DKIM is highly recommended to improve deliverability.


When sending bulk emails, it’s critical to adhere to the authentication and deliverability standards imposed by major email providers to ensure successful inbox placement.

  • Authentication Standards (DMARC, DKIM, SPF):
    Providers such as Google (Gmail) and Yahoo now require proper configuration of DMARC, DKIM, and SPFrecords for domains that send bulk emails. Failure to comply with these standards can result in:

    • DMARC or Policy Bounces: Emails rejected outright due to authentication failures.

    • Poor Deliverability: Emails may be routed to spam or fail to reach inboxes altogether.


  • Sending Volume Limits (Microsoft & Others):
    Some providers like Microsoft (e.g., Outlook, Hotmail, Office365) implement throttling mechanisms that limit the number of emails that can be received per sender per day. A common threshold is 5,000 emails per day. Exceeding this limit can lead to:

    • Deferred Deliveries: Emails are temporarily delayed and retried later.

    • Permanent Failures: If retry attempts exceed time limits or if volume limits are repeatedly breached.

    • Reputation Impact: Frequent throttling or bouncing may negatively affect your domain's sending reputation, impacting inbox placement across other providers as well.


Best Practices:

  • Monitor email sending volumes per domain and per provider.

  • Gradually ramp up sending for new domains/IPs (a.k.a. warm-up).

  • Segment campaigns and respect provider-specific thresholds.

  • Ensure all authentication protocols are properly set up and tested.


Failing to meet these technical and volume-related requirements not only risks delivery failures but may also jeopardize your ability to engage with your audience effectively.



Setting up DKIM

DKIM (DomainKeys Identified Mail) acts as a safeguard against email spoofing. In CustomerGauge, configuring DKIM includes setting up CNAME records in your DNS provider. These records enable receiving mail servers (e.g., Gmail) to verify the email's signature associated with your domain. You can obtain the DKIM records by clicking 'View DNS records' for your domain. 



Setting up SPF

SPF (Sender Policy Framework) verifies the authorization of the sending email server for a specific domain. Adding CustomerGauge's SPF record to your From Address domain enhances authentication by listing IP addresses or domains used for sending emails. You can obtain the SPF record by clicking 'View DNS records' for your domain.



Setting up DMARC

DMARC (Domain-based Message Authentication, Reporting, and Conformance) offers additional protection against email spoofing. Setting up a DMARC record enables inbox providers to handle emails failing SPF and DKIM checks according to specified policies. DMARC causes email servers to verify alignment, ensuring that the domain in SPF or DKIM matches the domain in the email's "From" header. This prevents phishing attempts that falsely claim to be from a different sender. DMARC also provides domain owners with reporting on email authentication and usage. Customizing DMARC policies allows businesses to tailor authentication measures to their requirements.



Explanation of values

DMARC policies can be defined by adding a TXT record in your DNS provider settings, with a value that can include the following semicolon-separated properties:

  • v: the version of DMARC.
  • p:type of policy that dictates how to process emails that do not pass authentication. This can be any of the following:
    • none: used to collect feedback and gain visibility into email streams without impacting existing flows.
    • quarantine: filter emails that do not pass authentication into the recipient's quarantine.
    • reject: bounce emails that do not pass authentication.
  • sp: used to apply a policy to a subdomain of the DMARC record.
  • pct: the percentage of total unique sends that failed authentication to apply this policy to. For example, if your DMARC record included p=reject; pct=25, and 100 emails failed authentication, only 25 of them will be bounced, while the other 75 will be delivered to their recipients.
    • Define this property to slowly ramp up your authentication policy to ensure it's working as expected.
    • This parameter can be ignored by certain inbox service providers.
  • ruf &rua: two optional parameters that specify an email address to send DMARC reporting data to. These must be provided in URI mailto format (e.g., mailto:reporting@example.com). The reporting data that's sent differs based on the parameter: 
    • rua: an aggregate report of all your domain traffic.
    • ruf: failure reporting data that includes redacted copies of individual messages that failed authentication.
  • adkim & aspf: specifies the alignment mode for DKIM and SPF. These should both be set to r (i.e., a relaxed alignment). A relaxed alignment should be the default setting for DMARC for DNS services.



Example use cases



Neutral policy

v=DMARC1; p=none;

This example shows a neutral DMARC policy with no additional parameters. A neutral policy is useful for senders who are just starting to get familiar with DMARC. This is the bare minimum for DMARC to function.



Quarantine policy with failure reporting

v=DMARC1; p=quarantine; pct=25; ruf=mailto:reporting@example.com;

This example shows a policy that will quarantine 25% of emails that fail authentication, while the other 75% of emails that fail authentication will be permitted for delivery. The policy also provides a reporting address where an individual notification email can be sent for each email that fails authentication. This is typically used when working on strengthening your authentication policy.



Strict policy with aggregate reporting

v=DMARC1; p=reject; rua=mailto:reporting@example.com;

This example shows a strict DMARC policy to bounce any emails that fail authentication, and provides an email address to send aggregate reporting data to. This is typically used when you have high confidence in how the domain is used.



Please note: CustomerGauge Support can't assist with DMARC record setup. You should contact your IT team (or the person that handles your DNS settings) for help. You can also use third-party DMARC consulting services for extra support.