Knowledgebase

Featured article

(Article Updated - August 2024) Overview A blocklist is a database of IP addresses or domains that have been associated with the sending of unsolicited commercial email or spam. Internet Service Providers (ISPs) and business email networks use information from blocklists to filter out unwanted email. As a result there can be a drop to inbox delivery rates if the IPs or domains involved with sending email are listed on a blocklist. Marketo’s Email Delivery and Compliance team monitors blocklist activity on our IPs and domains daily. When an impactful listing occurs, we reach out to the blocklist, attempt to identify the sender that triggered it, and work with the blocklist organization to get the listing resolved. There are thousands of blocklists, most will not have a significant impact on your delivery rates. Below, we have compiled a list of the blocklists that commonly appear across our sender ecosystem. Each blocklist has been grouped into a top tier (Tier I) by most impactful, to the bottom least impactful tier (Tier III). These may have little to no impact across our sender network. Tier I Blocklist Spamhaus (SBL) Impact: Spamhaus is the only blocklist that we categorize as a Tier I for a reason: it has by far the greatest impact on delivery. It is the most well-respected and widely used blocklist in the world. A listing at Spamhaus will have a negative effect on your ability to deliver emails to your customer’s inbox and can cause bounce rates of over 50%. Evidence suggests that most of the top North American ISPs use Spamhaus to inform blocking decisions. How it works: Unlike many blocklists, Spamhaus lists senders manually. This means they are proactively watching sender activity, collecting data, and base listings on a number of variables. Most commonly senders are listed for mailing to spam trap addresses that Spamhaus owns. Sometimes Spamhaus will list senders based on recipient feedback as well. Next Steps: Please note that every Spamhaus email can be quite different depending on the information provided and the nature of the listing . Because Spamhaus has multiple types of listings, the remediation steps are based on which type of blocklisting has occurred. We have listed the most common types to affect Marketo customers, from most to least impactful. Impact can range from a full block of top severity, to a partial block that is less severe (CSS Data, DBL). If remediation isn’t performed and the problem not addressed, these listings can increase in severity and turn into a full blocklisting. Spamhaus Blocklistings Types SBL (full blocklisting) Considered the most impactful. Remediation steps: Our team monitors closely for Spamhaus listings. Once alerted to the listing, we send an email notifying the customer, and reach out to the Spamhaus contact to start the remediation process. Only a Marketo delivery team member should be in direct correspondence with the Spamhaus contact, to speak on behalf of the customer, and to relay their questions and instructions, ensuring quick resolution and reduced impact. Senders that trigger this listing on a shared IP range will be moved to a more isolated, penalty range (IPB), so as not to impact the other shared senders. Those affected on a Dedicated IP, only impact their own sending and will not be moved. However, depending on the severity of the issue, our team may need to revoke a customer’s ability to send any emails until full resolution. The listing will last until Spamhaus is satisfied that the offending sender has taken the appropriate steps to mitigate the problem. SBL CSS Customers are alerted of the listing with an email containing all the information needed to immediately begin the remediation process. This is part of an automated trigger listing, that allows for a customer to delist directly on the Spamhaus website, after they’ve completed remediation. Remediation steps: Customers will go to the Spamhaus IP lookup website, at https://check.spamhaus.org, where they can check on the status of their IP and continue to monitor it in real time, until it is no longer listed there. Follow the remediation and delisting instructions provided, and check for specific details in the blocklist notification email. DBL (Domain blocklisting) Customers will receive an email notification alerting of the company domain being listed. The email will contain specific information to help narrow down and identify which email source likely triggered it within Marketo. It’s important to note that any email sent from outside of Marketo, that contained the company domain, is suspect. This means, if the sender uses multiple IPs and/multiple email platforms, then any of those could be the source. Remediation steps: Follow the detailed instructions in the email, which will also provide a link to the Spamhaus Domain reputation checker webpage, to check the real time listing status of the affected domain. Once the email source is identified and cause addressed, this customer will follow the online instructions to request to be delisted. Tier II Blocklist SpamCop Impact: SpamCop is not used by any of the major North American ISPs to inform blocking decisions, but it makes it to the Tier II list because it can have a significant impact on B2B email campaigns. SpamCop is considered a Tier I one blocklist for B2B marketers but a Tier II for B2C marketers. SpamCop is a dynamic IP blocklist, that can affect a single IP or a subset of IPs Typically, the block will automatically lift within one business day, but can take longer for relisted IPs. To have triggered a SpamCop listing likely means the sender has a list management problem that should be addressed. How it works: SpamCop lists IPs for one of two reasons: Either the email hit SpamCop spam trap addresses OR A SpamCop user has reported the email unwanted. Most of SpamCop’s spam traps are previously valid addresses that have not been active for 12 months or longer. Remediation steps: If you are seeing a significant number of bouncing emails caused by a SpamCop blocked IP but aren’t sure if your email activity triggered the listing, first identify whether you are sending on a shared sender network or not. If sending from a shared IP range when this occurs, you or any other customer sending from the same network may have contributed to the IP block. This IP block will automatically get dropped within a business day. For those on a Dedicated IP that trigger a listing, refer to the above remediation steps and resources, to address the list management issue. Tier III Blocklist (Low/ No impact ) These are considered the lowest tier and therefore cause the least impact across the Marketo sender ecosystem. Some of these blocklists were more impactful at one time, while others are only impactful based on the sender region (Manitu). Others still can suddenly flare up (Lashback). There are also many blocklists that are ignored (0spam), and are not taken seriously because they do not provide any means to delist once on the list (NoSolicitado) or that they charge money to have the listing removed ( UCEPROTECT ). The pay-to-delist model is not well respected in the email industry. When using blocklist tool checkers, such as MXToolBox, many blocklists will appear, but very few are relevant. Here is our selection of Blocklists you may come across that are least impactful: Project Honey Pot SpamAssassin URIBL/SURBL DrMX PSBL 0spam HostKarma Ascams ZapBL Barracuda Trendmicro Inc. Cloudmark Proofpoint Invaluement ISP Blocklists Some ISPs use internal blocklists to make blocking decisions. Examples include AOL, Yahoo, Gmail, Outlook and Hotmail. If your IP is being blocked by one of these networks, and those networks have a large presence in your lists, a block of this kind could have a noticeable negative impact on delivery. Marketo monitors for significant ISP blocks. Those experiencing deliverability issues with emails not making it to the Inbox and bulking in the spam folder may benefit from additional services with our Email Delivery Consultants. Remediation Steps: Email Delivery Compliance Team works to resolve any ISP blocks. ISP blocks are are usually resolved or lifted within less than 24 hours of a delisting request. Customers experiencing significant blocks for Microsoft domains (outlook.com, live.com, microsoft.com), can submit a request to the delivery team to seek mitigation on their behalf. Additional Resources: Blocklist Deep Dive Abuse Report Deep Dive What is a spamtrap, or spam trap, and why does it matter? Blocklist remediation Blocklist resolution flowchart Successful lead reconfirmation What is a blocklist?

This document provides an overview of the recent Munchkin Activities Recording Issue that impacted a subset of customers across our data centers beginning on April 24, 2019. All customers that were impacted were emailed details of the incident on May 1, 2019. If you are unsure if your instance was impacted, please reach out to Marketo support at support.marketo.com. Start time: London data center, April 24, 2019, 4:30 PM PDT Sydney data center, April 26, 2019, 2:00 PM PDT San Jose and Ashburn data centers, April 26, 2019, 5:30 PM PDT How to identify what data center your instance is located in: You can deduce the server locations by looking at the URL of your instance. The CNAME=the pod or server your instance is on. The example above indicates that this instance is in our Ashburn data center. The abbreviations for all our data centers are as follows. lon = London sn = Sydney sj = San Jose ab = Ashburn End time: Updated patch was pushed April 30, 2019, 3:40 PM PDT Service affected: A subset of Marketo customers may have experienced Munchkin activities coming from web pages (clicks, visits) that were not being logged in activity logs. Since the activities were not immediately registered, any Trigger Campaigns set to initiate when those activities occurred would not have been triggered. What happened: This issue originated from a patch deployed during a recent release. The patch was designed to update the process used to determine if a subscription’s web traffic should be retained. An error in the patch code caused one of the evaluation parameters to be missed, resulting in web traffic activity not being logged. Remediation: Once the cause was identified, our team developed and deployed a patch on April 30, 2019, to correct the piece of code that introduced this issue. To backfill the activity data that was not recorded during the impacted timeframe, our team has developed a script to restore the data back into our activity logs, so no data will be lost. We expect this data fix to be complete on May 24, 2019. Campaigns that would have been initiated by the activities that occurred during the impacted timeframe will not be replayed. If you need assistance to identify which smart campaigns were active during this incident, our Campaign inspector is a great tool to assist you. You can use this to search for active campaigns that use specific triggers (“visits web page” or “clicks link on web page”). Replay Impacted Smart Campaign: After you have identified the smart campaigns that may have been impacted, create a new smart campaign using the following smart list filters. For smart campaigns triggered by clicking a link on a web page, use the following filters. Select the applicable link and timeframe based off what data center your instance is located in. The second filter is to prevent activities that were not impacted by this incident. For smart campaigns triggered by a web page visit, use the following filters. Select the applicable web page and timeframe based off what data center your instance is located in. The second filter is to prevent activities that were not impacted by this incident. After the smart list is set up, the flow steps should mirror the flow steps of the original smart campaign that you wish to replay. If you experience any issues with replaying the impacted smart campaigns, please contact Marketo support at support.marketo.com, or through any of the methods listed here.

Where can I find the answers I need? Search Product Docs and Knowledgebase Articles The search bar on the front page will search both Product Docs and the Support Knowledgebase. If you need to drill down for a deeper search, you can access the Knowledgebase via the link at the top of the Support Space, or you can go to our Product Documentation site, docs.marketo.com. The Knowledgebase focuses on troubleshooting specific issues, while the Product Docs site contains more feature overviews and how-to's. Support Blog The Support Blog contains posts on product changes, new product features, in-depth discussions on topics such as security and deliverability, and changes and enhancements to the Support portal. How do I contact support? Submit a case Regional Support contact information Chat Support

What change is being made? Marketo Sales Connect/Toutapp will no longer be supporting our legacy .Net Add-In for Outlook, as of May 19, 2019. Because Marketo made a replacement add-in available in February 2019, we expect minimal impact as there are teams that have already been progressively migrating on to the new add-in. However, it’s important to note that the .Net Add-In will not stop working on May 19, 2019 – it will just stop being supported. If you experience an issue when trying to use the .Net Add-In on or after May 19, 2019, you will be directed to update to the new 0365 Add-In. Screenshot of .Net add-in buttons Why is this changing? In recent updates, the O365 Add-In reached feature parity with the .Net Add-In, making .the Net Add-In a redundant experience. The O365 Add-In takes advantage of Microsoft's advanced API’s and delivers a superior experience that works across Windows and OS operating systems as well as in browsers. With quality and stability being the focus of this change, Marketo wants users to update to the new 0365 Add-In. What action is required? After May 19th, the .Net Add-In will continue to work for any customers who have it already installed. However, Marketo will no longer support troubleshooting this version, and any customers reporting issues will need to upgrade by completing the following steps:The new newly released 0O365 Add-In, released on Feb 26, 2018, has feature parity with the old .Net Add-In and is built on Microsoft's advanced API’s. Individual users will need to complete the following steps to upgrade: NOTE: The O365 Add-in is only supported by Outlook 2013 and higher. Users who are running a version of Outlook 2010 or older will need to upgrade their version of Outlook before installing the O365 Add-In. How to uninstall the .Net Add: http://docs.marketo.com/display/public/DOCS/How+to+Uninstall+or+Reinstall+Sales+Engage+from+Outlook How to install the O365 Add-In: http://docs.marketo.com/display/public/DOCS/Installing+Sales+Engage+for+Office365+Mac+OS%2C+Windows%2C+and+Online

Overview Marketo launched the new Email Editor 2.0 with the Spring ’16 release. Email Editor 2.0 is fully backward compatible with Email 1.0 emails and Email 1.0 email templates and also provides a large number of added capabilities. For this reason, after June 18th Email Editor 1.0 and Email Template Editor 1.0 will no longer be available within the Marketo application. All Marketo subscriptions that have yet to enable Email Editor 2.0 will be seamlessly transitioned to Email 2.0 on this date. Note: This change is not tied to a Marketo Release. What are some benefits of using Email Editor 2.0? With Email 2.0, you will enjoy a more modern experience and even more capabilities when editing emails in Marketo. Here’s what you’ll see in your Marketo Engagement Platform: Modules: Defined at the template level, modules are sections that group content elements (images, text, etc.) you can add to your email assets. You can also clone the modules within your email asset, or place them in the most convenient location. Learn more about modules here: Add Modules to Your Email Variables: Email Editor 2.0 allows you to define variables within the email templates that you can reuse within the template or within email assets built based on the template. If necessary, users can modify the variable’s value when building emails. Variables come in several types like String, Color, Image, etc. We are confident variables will help you reduce errors and easily customize emails. Visit: Email Template Syntax - Variables for an in-depth review of email variables. Enhanced Editing Experience: The new Email Editor 2.0 also comes with an improved Email Previewer, which will allow you to see how your email would look like on a desktop and on a mobile device; a new Email Template Picker, so you can easily identify and select the template to start building emails, and a collection of fully responsive “Starter Templates” free of charge. For more information, please see our Email 2.0 Spring '16: Overview recorded session. Deprecation Details The ability to use the Legacy Email Editor 1.0 will be removed from the UI on June 18, 2019. Any emails created or edited after June 18, 2019 will automatically open the new Email Editor 2.0 version. Note that the Marketo APIs (Direct Writes & Clone Programs) will issue warning notifications to help you identify assets still needing to be upgraded to Email 2.0. Any 1.0 assets will still be usable in campaigns! They will simply be converted to the New 2.0 version the next time they are edited and approved (steps on how to do this are outlined below). While the UI will remove the option for users to create templates in the legacy editor, the APIs supporting the Legacy editors will not be removed from Marketo until the January 2020 release. Any assets that are not converted to the New Editor after January will not be usable and unavailable for conversion. After deprecation, attempts to write to or clone Email 1.0 assets will result in errors instead of warnings. Recommendation We recommend that your team enables 2.0 and gets familiar with the newest email editor prior to the June 18, 2019 UI deprecation date, to not only ensure they’re comfortable continuing to build and edit assets in Marketo, but also take advantage of the enhancements and added features mentioned above. Frequently Asked Questions (FAQ) How do I know which email editor I’m using? There are 2 ways to figure that out: 1. In the Email section within Admin, select the ‘Edit Email Editor Settings’ option. The application will display a dialog window and indicate the email editor configured for your Marketo subscription, as in the image below: 2. Edit an email asset and see what the editor looks like: Here’s the Legacy Email Editor: Here’s Email Editor 2.0: As a reminder, after June 18, 2019, any emails you created in Email Editor 1.0 will remain in your subscription and still function. However, you won’t be able to create any new emails with Email Editor 1.0. How do I convert my assets from using Email Editor 1.0 to 2.0? These steps below will guide you through converting any assets using Email Editor 1.0 to 2.0: 1. Confirm that you have enabled the New Editor (2.0) in your admin settings by navigating to the Admin Panel > Emails > Email Editor Settings > Select “New” > Save If you already are using the New Email Editor (2.0), then disregard this step 2. After identifying which assets require the conversion, please navigate to the asset in the Tree in Design Studio (or Marketing Activities if the asset lives in a program) 3. Right-Click on the Email and click on “Edit Draft” 4. The screen should now display the editor in the New Editor (2.0) 5. Make changes, if any are needed, and click “Approve and Close” 6. Now this email has been converted and you are free to use this email with Editor 2.0!

**Nov. 11, 2019 update: In a continued effort to integrate with Adobe's release structure, we are shifting the deprecation of TLS 1.0 and TLS 1.1 to January 13, 2020. To align with Adobe’s world-class standard for security, we will be deprecating support for Transport Layer Security (TLS) 1.0 and 1.1 starting December 13, 2019 January 13,2020. Systems integrating with Marketo that are not compliant with 1.2 protocol could potentially lose access to Marketo Engage services. To maintain your Marketo Engage access, please ensure that all client systems are TLS 1.2 compliant before January 13, 2020. For a list of TLS 1.2 compliant browsers and frameworks, see the tables at the bottom of this communication. What is Transport Layer Security (TLS)? Transport Layer Security (TLS) is a security protocol that provides privacy and data integrity between two communicating applications. It is deployed widely for web browsers and other applications that require data to be securely exchanged over a network. TLS includes two layers: the TLS Record protocol and the TLS Handshake protocol. The Record protocol provides connection security. The Handshake protocol enables the server and client to authenticate each other and negotiate encryption algorithms and cryptographic keys before data exchange. Why is Marketo Engage making this change? Most requests for Marketo Engage web services originate from TLS 1.2 compliant systems, with low traffic from TLS 1.0 and 1.1 systems. TLS 1.0 was first published in 1999, with newer versions 1.1 in 2006, and 1.2 in 2008. As technologies age, security threats evolve, and so must industry standards. To stay aligned and protect our systems from security risks identified with older TLS versions, we are mandating a minimum TLS 1.2 supported connection to ensure secure connections. There have been documented attacks against TLS 1.0 using an older encryption method and the older versions are more vulnerable than TLS 1.2. For more information, see Attacks Against TLS/SSL. When will this change happen? TLS 1.0 and TLS 1.1 deprecation will take place on January 13, 2020. After the date of deprecation, you will not be able to connect to Marketo Engage services using browsers or applications not compatible with TLS 1.2. Marketo Engage encourages users to quickly abandon older versions of TLS to avoid exposure to security vulnerabilities. How does TLS affect you? Marketo Engage services are web-based and can only be engaged through a secure network connection. TLS helps ensure a secure and reliable connection between your browser or server and Marketo web services, which includes anything that uses Marketo’s API, such as REST, SOAP, Munchkin, RTP, Mobile, and more. As technology evolves, security standards are upgraded to ensure higher levels of privacy and data integrity. However, older applications are not updated to include the latest standards. As the acceptable level of security rises, these older, less secure applications are left behind. To be able to connect to Marketo Engage services, update your browsers and application frameworks to a version that supports TLS 1.2. How does TLS affect your customers? Marketo Engage landing pages will be served to your visitors through TLS 1.2 secured connections. Any browser updated since late 2013 (except Chrome, updated since 2017) will be TLS 1.2 compliant; further, Apple, Google, Microsoft, and Mozilla have all announced their plan to completely disable TLS 1.0 & 1.1 support by the first half of 2020, so we expect very minimal impact to visitors. If visitors report a loss of connectivity to Marketo Engage hosted landing pages as a result of this change, they will need to update to a compatible browser version. What error message will return to a non-compliant connection? The exact error messaging returned depends on the browser or application framework being used to connect to Marketo Engage web services. Some examples include but are not limited to: Unable to connect to the service Service not available Error in connection To resolve these errors, the browser or application framework must be updated to a version compatible with TLS 1.2. TLS 1.2 Compatibility Desktop Browsers Desktop Browser Compatible Versions Release Date Google Chrome V30+ March 20, 2017 Mozilla Firefox V25+ October 29, 2013 Internet Explorer IE 11 October 17, 2013 Microsoft Edge All versions Opera V17+ October 8, 2013 Apple Safari V7+ October 22, 2013 Mobile Browsers Mobile Browser Compatible Versions Google Android OS Browser Android 5.0+ Chrome for Android V30+ Firefox for mobile V27+ Opera Mobile V57+ Apple Safari IOS 5+ Application Frameworks Java .NET OpenSSL Java 8, or later .NET 4.6, or later OpenSSL 1.01, or later Java 7, with TLS 1.2 enabled in app .NET 4.5, with TLS 1.2 enabled in app

As of November 30, 2019, all the familiar content on the Marketo Engage Status Pagehas been migrated and is now available on the Adobe Status Page .This move allows us to leverage Adobe’s more robust and efficient monitoring platform for not only the standard alerts and scheduled maintenance, but also hotly-requested functionality including pod-specific status updates and proactive notifications! Timeline October 31, 2019: The functionality to subscribe to notifications at the solution and pod level released on the Adobe Status Page. Customers may begin exploring and subscribing to various notifications. November 30, 2019: Marketo Status Page was deprecated and a redirect to Adobe Status Page was put in place. Moving forward, please refer to this article for up-to-date System Uptime and Deliverability Scores. January 8, 2020: To better prepare you for upcoming changes and scheduled maintenance, we have increased the previous two-day ‘lead time’ of these notifications based on impact. Service Maintenance 30-day lead notifications are now available on Web/Mobile/Tablet surfaces and via Email notifications. Opt-In to Adobe Status Page Subscriptions For step-by-step instructions on how to opt-in to Adobe Status notifications, please refer to this article: Subscribe to Adobe Status Notifications Common Questions How do I see previous issues or maintenance? 1. Go to: https://status.adobe.com/ 2. Click "Experience Cloud" 3. Click "Adobe Marketo Engage" 4. Select the appropriate Service 5. Click the dots on the date line to view the details of what occurred on that day What do the colors mean on the Status page? 1. Blue is for maintenance 2. Red is for a major issue 3. Orange is for a minor issue

This document only applies to a subset of Marketo customers that were contacted on August 26, 2019. If you are unsure if this applies to your Marketo subscription, please Contact Marketo Support at support.marketo.com. Overview GoToWebinar is changing its authentication protocol used for API access. Their legacy protocol, OAuth v1.0, will no longer be used after October 1, 2019, and all services accessing GoToWebinar (Marketo) will be required to use the new authentication protocol, OAuth v2.0. Marketo is updating our system for a subset of Marketo customers to utilize the OAuth v2.0 authentication protocol for new login authentication. All newly initiated service authentications between Marketo and GoToWebinar will use OAuth v2.0. However, all existing GoToWebinar services currently logged in and in use now must be reauthenticated manually. All customers who use GoToWebinar must reauthenticate each of the logins for these services in your Marketo instance by navigating to Admin > LaunchPoint. Any API calls still using OAuth v1.0 after October 1 will fail. This will result in statuses not being shared between Marketo and GoToWebinar and will prevent users from syncing Event programs with a GoToWebinar event. FAQ Why is this change happening? GoToWebinar is strengthening its security protocols for API login access to their services. This requires using an upgraded version of the login protocols, known as OAuth v2.0. Is this a Marketo change or a GoToWebinar change? This change is being implemented by GoToWebinar to strengthen its security protocols. Marketo has upgraded our system to allow a seamless transition, but the protocol change is being made by GoToWebinar. When does this take effect? The new protocol version OAuth v2.0 is active and in place now. GoToWebinar has placed an announcement on their status page stating that the deprecation of the legacy OAuth v1.0 is scheduled for October 1, 2019. All connections between Marketo and GoToWebinar that are still using the legacy OAuth v1.0 protocol will be refused by GoToWebinar after that date. This includes new access requests as well as those currently active and in use. What do I need to do? Reauthenticate your GoToWebinar services with a fresh login from within your Marketo instance before October 1, 2019. Why do I have to do it myself? Marketo has made the changes necessary to utilize OAuth v2.0 for new authentication logins being made moving forward. However, all logins already in use were initiated on the older protocol, OAuth v1.0. Marketo doesn’t know your personal login credentials, so you need to do the reauthentication directly. Is there a different procedure for how to enter the credentials inside the Marketo UI? No. The update Marketo made was on the back end, so there is nothing different to how you enter the info. The UI is the exact same as it was. What happens if I don’t reauthenticate the login before October 1, 2019? All connections between Marketo and your GoToWebinar services will be refused by GoToWebinar on their end. If I miss the deadline and the connection is shut off, how will I know? You’ll find error messages in your Marketo instance where the services are used. See the section below for “Symptoms of a disconnected service” to know what to look for. If I miss the deadline and the connection is shut off, how do I get it working again? Reauthenticate your login credentials in Admin > LaunchPoint. See the “Customer Action Needed” section below for step by step directions. Customer Action Needed A subset of Marketo customers who were notified through email must reauthenticate GoToWebinar login credentials for each user. This must be done before October 1, 2019, to avoid experiencing disruption of your services. 1. Navigate to Admin 2. Click LaunchPoint to open the list of Installed Services 3. Click and open the GoToWebinar service to edit it 4. Click the Log into GoToWebinar button. 5. In the GoToWebinar Sign In pop-up window, enter your GoToWebinar email and password and click Sign In. 6. After the window closes, click Save DONE! By reauthenticating the login, you’ve ensured that the service is using the new OAuth v2.0 protocols. Symptoms of Disconnected Service Here is a list of what to expect if the integration with GoToWebinar is disconnected due to the deprecation of OAuth v1.0 on October 1, 2019. 1. The service listing in Admin > LaunchPoint will have a status of Failed along with a few details. A. Reauthenticating your login credentials will resolve these errors. 2. Event programs that have not yet synced with GoToWebinar will be unable to sync and will return errors. A. Reauthenticating your login credentials will resolve these errors. B. For reference, here is the documentation on how to sync an Event Program to GoToWebinar. 3. Existing programs that were synced with GoToWebinar prior to the deprecation will show no difference. However, if anyone is added to the program with a ‘Registered’ status, Marketo will attempt to push this record to GoToWebinar and will fail due to the deprecation of the OAuth v1.0 protocol. This will give the record a status of ‘Registration Error’. If this occurs, this data is not lost. A. Reauthenticate the GoToWebinar service B. Manually refresh the webinar attendance. Navigate to the Event Actions menu of your Event Program and select Refresh from Webinar Provider 4. Records that were already registered with GoToWebinar before the service stopped will still be able to receive the correct {{member.webinar url}} token. That data for the token will already be in Marketo, so reminder emails will still have the right links to the actual webinar even if the service was stopped after they were registered. The attendee report won’t be able to come down from GoToWebinar with the connection cut off, but at least your leads will still have the link to get to the webinar. 5. If the service is no longer active and an existing webinar completes, normally this would record attendance information and sync this back to Marketo and change the status of program members. However, if the service is inactive, this will fail silently, and no status change will occur. Manually refreshing from webinar provider will also silently fail if done while the service is still inactive. The notification will show that there are no updates. A. Reauthenticate the GoToWebinar service B. Manually refresh the webinar attendance. Navigate to the Event Actions menu of your Event Program and select Refresh from Webinar Provider C. Now that the credentials were reauthenticated and the service is back online, the manual refresh will work properly. How to Get Additional Help Feel free to ask questions in the comments section of this documentation. Our Support team will be monitoring the comments to help answer your questions. You can alsoContact Marketo Support at any time.

Issue Description Windows Outlook users who use the Marketo Sales Connect plugin might have noticed that emails don't send as fast as they usually do. Unfortunately it takes a little longer than usual on this particular platform due to a recent MSC plugin update. We are working on a long-term fix for this subset of customers, but in the meantime you can use the following workarounds: Issue Resolution If you switch Outlook to, "Online Mode" (as opposed to Cached Exchange Mode) this will decrease the total sending time. You can follow this document in order to turn off Cached Exchange Mode. If you would like to learn more about the differences between Online Mode and Cached Exchange Mode, you can read more here. Alternatively, you can also use the Web version or Mac version of Outlook to address this issue. Who This Solution Applies To Windows Outlook users who utilize the Marketo Sales Connect plugin.

Background This document provides additional details for customers that were impacted by the June 11, 2019 Communication Limits issue. “Send Email” activities are generated in real-time. These activities are stored in a queue, where our back-end process removes them on a first-in, first-out basis. The process then converts them into an aggregate count of sent emails on a per-lead basis, with an associated timestamp. We process these activities at 2,000 activities per batch. Frequently Asked Questions (FAQ) What email smart campaigns could have been affected? During the impacted timeframe, both trigger and batch email campaigns could have been affected. A batch campaign with more than 2,000 leads is likely to have been affected. Trigger campaigns and batch campaigns with less than 2,000 leads could have been affected, but not as likely, as described below. Why are batch email campaigns with more than 2,000 leads likely to have been affected? When a large batch campaign is run, a large influx of Send Email activities are sent to the queue. For example, if a campaign sent out 10,000 emails, the back-end process would take the first batch of 2,000 activities and keep track of the email send count on a per-lead basis. After finishing the 1st batch, the tracking process normally moves on to count the next 2,000 activities. However, this issue caused the first 2,000 activities to be re-processed multiple times (up to 5 times). In this scenario, the first 2,000 leads who were sent an email would have a count of up to 5 emails sent when it should have only been 1 email. For the remaining 8,000 leads, they would not have been processed, resulting in a count of 0 emails sent to each of these remaining leads. Why are batch email campaigns with less than 2,000 leads not as likely to have been affected? This is because we process a batch of 2,000 Send Email activities at a time. If there were no further Send Email activities in the queue at the time of the back-end processing, this issue would not have caused activities to be re-processed. Why are trigger email campaigns not as likely to have been affected? Trigger campaigns only initiate under specific conditions. In the most common uses of trigger campaigns, it is unlikely that there would be an influx of trigger campaign execution that would have resulted in a large number of Send Email activities during a short period of time. For example, consider a trigger campaign that is set to send an email every time a lead fills out a form on a specific landing page. It is unlikely that there would be such a surge of leads filling out more than 2,000 forms in a short period of time, which would lead to the processing of more than 2,000 Send Email activities unless there was a big marketing effort to drive these leads to such landing page. Can you provide a list of the trigger email campaigns that were affected? Unfortunately, there is no way for us to obtain this information. The queue that stores such data has already been processed and the content was removed after processing. Can you provide a list of the batch email campaigns that were affected? We cannot recover this information due to the same reason listed above. However, the data can be obtained manually by following the steps below: 1. If you know what campaigns were run during the impacted time-frame, you can check each campaign and see whether there were more than 2,000 emails sent. 2. The Email Performance report can also be used to identify the possibly affected campaigns. a. Navigate to Analytics > Email Performance report b. Under Setup, set the Sent Date to the impacted time-frame based on the data center your instance is in. London Data Center: June 11, 2019 – June 24, 2019 Sydney, San Jose, and Ashburn Data Centers: June 14, 2019 – June 24, 2019 c. Run the report and Sort the Sent column in Descending Order to identify email sends greater than 2,000. d. Locate the email in question and click on the Used By tab to identify the campaign(s) that were used to send this email. In addition, please ensure that this is a non-operational email (operational emails were NOT affected by this issue). e. Navigate to the smart campaign and Click on the Email tab to confirm that more than 2,000 leads were sent the email. f. Click on the Run History tab to confirm that more than 2,000 leads were sent this email in a single campaign run during the impacted time-frame. If you have additional questions or experience any issues, please contact Marketo support at support.marketo.com, or through any of the methods listed here.

Update May 2021: Due to the release of CNAME Cloaking Defense with IOS and Safari 14 Munchkin cookies will be capped to a 7 day lifespan in Safari . What’s changing? On February 21, 2019, Webkit announced the new release of Safari’s Intelligent Tracking Prevention (ITP), known as ITP 2.1 and ITP 2.2 shortly thereafter. With ITP 2.x, all persistent client-side cookies, i.e., non-session cookies created via JavaScript through document.cookie, are capped to a seven-day or one-day expiry. Mozilla Firefox and Google Chrome have also announced their intent to conform to these new policies, though no details or dates have been released. How does this impact Marketo? As a result of these changes to cookie policy, 7 days after their initial tracked visit to your domain, the Munchkin cookies of visitors using Safari (or future affected browser versions) created with the existing versions of Munchkin JavaScript will expire, and on subsequent visits they will be tracked as a new visitor. How does Munchkin operate? On a person’s first visit to a page on your domain, a new anonymous person record is created in Marketo. The primary key for this record is the Munchkin cookie (_mkto_trk) which is created in the user’s browser. All subsequent web activity on that browser is recorded against this anonymous record. In order to be associated with a known record in Marketo, one of the following methods should be used: The person may visit a Munchkin-tracked page with a mkt_tok parameter in the query string from a tracked Marketo email link. The person may fill out a Marketo Form. REST Associate Lead call must be sent. Once one of these actions is completed, the cookie and all its associated web activity will be associated with the known record. How is Marketo planning to address ITP concerns? Marketo will implement a new web service to allow Munchkin cookies to be set with a Set-Cookie header via HTTP response, so that they may bypass the 7-day expiry cap imposed when setting cookies via JavaScript. Do I need to do anything to take advantage of these updates? In order to leverage the new behavior and take advantage of the greater expiry period and tracking capabilities, ensure that you have configured the following: A Landing Page CNAME Secured Landing Pages (i.e. HTTPS) For external pages, you must have configured a Landing Page Domain or Domain Alias with a Top-Level Domain (TLD) matching the external domains which you wish to track For example, if you have pages on the domain www.example.com which are tracked, you must have configured an LP Domain or Alias which is a subdomain of example.com, like munchkin.example.com What happens if I do nothing? Munchkin’s ability to track users across sessions on the same domain will remain limited by ITP to either 1 or 7 days based on the browser and browser version used by the visitor. As of this posting, this only affects visitors using the Safari browser, although Chrome & Firefox may follow suit with their own versions. When will the solution be launched? These changes will begin as a staggered roll-out to customers who have opted into the Munchkin Beta channel in conjunction with the January 2020 Marketo release. Once the solution has been released to all beta customers, the roll-out to our entire customer base will begin in mid-to-late February. All customers should expect to have the solution by end of March 2020. Google Chrome Update (Feb. 2020): Google recently announced that the Chrome browser will block all third-party cookies within two years; however, since Marketo uses 1st party cookies, this update regarding 3rd party cookies will NOT affect your Marketo tracking efforts. For further context about 3rd party cookies in general, and the industry shift away from using them, please see the following article for Adobe's stance across the Experience Cloud Solutions: medium.com/adobetech/an-adobe-perspective-google-chromes-announcement-on-the-future-limits-of-3rd-party-cookies-bbb7bb257fdb

Issue Email Link Performance report on the same email shows more clicks compared to clicks in the Email Performance Report. Solution Email Performance Report clicks shows the total number of leads who has clicked any link in that email. This count is independent of any links and how many times a lead has clicked any link on that email. Email Link Performance shows the number of unique people who clicked each link. It shows the number of leads who clicked that particular link. The same lead could’ve clicked another link. So in the total it would be counted as 2 leads in the report but in reality both are same leads. This is the reason why you see Email Link Performance report shows more clicks compared to clicks in the Email Performance Report

Issue You have a Marketo form embedded on a non-Marketo page. When you open developer tools in your browser you see: "Error loading form: Object error: true errorCode: 400 message: "Subscriber <Your Munchkin ID> is not valid" " Solution The form embed code you are using is looking for your instance in the wrong place. Check the URL when you first log in to Marketo, make sure the sub domain in that URL matches what is in your embed code. For example: If you see app-sjst.marketo.com/ then make sure you have that same "app-sjst" in your embed code. Please note: This may vary between your sandbox and production instances.

Issue Clicking on a link in a Marketo e-mail that re-directs to a non-Marketo webpage destination does not open the page. Solution Complete the troubleshooting step below. If they do not resolve the issue, include the results in a Marketo Support Ticket. Check the CNAME is correctly setup for the email tracking link Check that the Default Branding Name matches the CNAME in Step 1 (check for typos). If you are unsure you can visit CNAME lookup on mxtoolbox and enter the default branding name to check. Under the Domain field enter your default branding name. Do you have SSL for tracking links enabled? If Yes, tracking links in emails should start with If No, tracking links in emails should start with If you do not have SSL enabled, but when you click the link it resolves to ,try a different network and see if it still occurs. Your network may be configured to automatically use HTTPS automatically even if the link is specified as HTTP. (Check with your network admin) If you are re-directed to the non-Marketo landing page but the page does not load: Check with the website admin if there are any redirect rules setup on the website. Try cutting out parts of the additional URL Parameter to see if that fixes the issue to identify which part of the URL parameter is causing it. Sometimes lead tokens or the mkt_tok may affect a redirect rule, since mkt_tok generates random characters and sometimes the token contains percentage '%' characters. It very common for websites to interpret a % followed by a character as an encoding. Seen in this website here If you are unable to resolve the issue in the steps above, provide the test results and information in a Marketo Support Case.

Issue After the switch to a secured domain (from http -> https), landing pages display both a broken format and mixed content warnings. Solution Make sure all links referenced in your Landing Page Templates and Landing Pages are secured, in other words served with the appended in the front and not Step 1: Open up Landing page with non secure warning sign Step 2: On Google Chrome right click on the page that is displaying the warning and select "Inspect." On Mozilla Firefox it's called "Inspect Element." Look for any "Mixed Content" warnings. Step 3: Find and address the links that are referenced in the error messages **If the link that is unsecure is a custom CSS file, these files will need to be moved and hosted in a secure location so that the links are loaded over https. Who This Solution Applies To Customers with Secure Domains for Landing Pages Service

Issue Duplicate records were sent an email from an Email Program. Solution While Marketo prevents sending emails to duplicate records (i.e. same email address) via the same Smart Campaign, it is possible to send an email to duplicate record when there is A/B test configured for the Email Program. Specifically, one record can be sent an email from the test send while the duplicate record can be sent the email from the winner send. For example, if there are two records for "mary@mail.com" in the audience, Mary can be sent two emails as follows: One record can be sent the email by qualifying for receiving the test from the sample size of the A/B test The other record can be sent the email by qualifying for receiving the winner from the sample size of the A/B test Note: sending the test and sending the winner utilizes individual campaigns which is why the systematic deduplication of emails within a smart campaign does not take effect for this scenario. To prevent this from occurring, exclude the duplicate records from the smart list of the email program.

Issue Issue Description Windows Outlook users who use the Marketo Sales Connect plugin might have noticed that emails don't send as fast as they usually do. Unfortunately it takes a little longer than usual on this particular platform due to a recent MSC plugin update. We are working on a long-term fix for this subset of customers, but in the meantime you can use the following workarounds: Solution Issue Resolution If you switch Outlook to, "Online Mode" (as opposed to Cached Exchange Mode) this will decrease the total sending time. You can follow this document in order to turn off Cached Exchange Mode. If you would like to learn more about the differences between Online Mode and Cached Exchange Mode, you can read more here. Alternatively, you can also use the Web version or Mac version of Outlook to address this issue. Who This Solution Applies To Windows Outlook users who utilize the Marketo Sales Connect plugin.

Issue Tracked links in emails resolve to "Your connection is not private", or other security warnings in the browser, when clicked. Solution The browser is expecting the branded link domain to be secured with a SSL certificate. Subscriptions without Secured Domains for Tracking Links: Please contact your Customer Success Manager to discuss purchasing a subscription to Secured Domains for Tracking Links. Subscriptions with Secured Domains for Tracking Links: Please contact Marketo Support to provision a SSL certificate onto your tracking link domain. More information can be found here Overview & FAQ: Secured Domains for Tracking Links

Issue In an instance where there are multiple workspaces, when creating a new email and right-clicking on a Marketo Starter Template to send a sample email, an error is displayed: Access Denied This error occurs even though the user has all permissions to Access Design Studio and all permissions to Access Marketing Activities. This includes the 'Run Single Flow Action' permission which is required for sending sample emails: "You must have the Access Database - Run Single Flow Actions permission to send sample emails." https://docs.marketo.com/display/public/DOCS/Send+a+Sample+Email Solution This error can occur if the user does not have access to the Default workspace. To solve this, the user must be provided with access to the Default workspace in [Admin > Users & Roles]

Included in this article Overview Troubleshooting Steps Overview If you have multiple workspaces in your Marketo Instance, your campaigns and smart lists may not pull the leads you would expect. If a lead partition is not visible to the workspace you are working in, there's no way for the smart list to "see" those leads in that partition. For more information about Workspaces and Partitions, check out Understanding Workspaces and Person Partitions Troubleshooting Steps To resolve this, you need to enable access for the specific lead partition to the workspace you are working in. This makes sure the workspace can "see" the leads and get them into your smart list or campaign results. 1. Under Admin, click on Workspaces & Partitions. 2. Select your Workspace and click Edit Workspace. 3. Edit the workspace and add check marks for all partitions that this workspace should be able to access. 4. Click the Save button. Your campaigns should now be able to access the leads in that partition and reflect the leads expected.

Knowledgebase

Maintaining a Directory of Leads Bouncing Emails

Top Blocklists - What You Need to Know

Munchkin Activities Recording Issue – Trigger Replay Overview

Understanding the Support Space in the Community

End of Life - Outlook .NET Add-In for Toutapp/Marketo Sales Connect

Email Editor 1.0 is Being Deprecated June 18th

TLS 1.0 & 1.1 Deprecation FAQ

Marketo Engage Status Page Migration

GoToWebinar Authentication Change – Take Action Before 10/1/2019

Outlook MSC Users Experiencing Slow Email Sends on Windows

Communication Limits Issue: FAQ

Browser Cookie Updates: How Marketo/Munchkin Is Affected

Email Performance Report and Email Link Performance Report Showing Different Click Counts

Embedded Forms Console Error: Subscriber '<Munchkin ID>' is not valid

Marketo Email Link Is Not Redirecting to a Non-Marketo Landing Page

Email mailto: Link Not Working

Switch to Secured Domain but Landing Pages Are Still Showing Mixed Content Warnings

Duplicate Records Were Both Sent an Email from an Email Program

Outlook Marketo Sales Connect Users Experiencing Slow Email Sends on Windows

Tracked Email Links Return "Your Connection Is Not Private"

Unable to send sample email from Marketo Starter Template

Leads not showing up in Workspaces & Partitions